106、数据库连接池设计：DBUtils、SQLAlchemy pooling、连接泄漏检测
106、数据库连接池设计：DBUtils、SQLAlchemy pooling、连接泄漏检测
从一次线上事故说起
凌晨两点，手机震得我直接从床上弹起来。生产环境的API响应时间从50ms飙升到15秒，数据库连接数飙到2000+，DBA在群里疯狂@我：“你们服务把连接池干爆了！”
我第一反应是“不可能，我明明配了连接池”。打开代码一看，脸都绿了——某个业务逻辑里，每次请求都new了一个新的数据库连接，用完直接扔那儿不管了。更骚的是，这个接口被爬虫疯狂调用，每秒钟几百个请求，每个请求都开一个连接，MySQL的max_connections直接被打满。
这就是典型的连接泄漏。你以为你配了连接池就万事大吉？天真。连接池只是帮你管理连接的复用，但如果你代码写得烂，池子里的连接照样会被你搞死。
连接池到底在解决什么问题
先别急着上代码，想清楚一个事：为什么需要连接池？
每次创建数据库连接，背后是TCP三次握手、MySQL认证、权限检查。一个连接建立大概需要几十到几百毫秒。如果你的接口QPS是1000，每次请求都新建连接，光握手时间就能把CPU干到100%。
连接池的核心就两件事：
- 复用连接：省去重复建连的开销
- 控制并发：限制同时打开的连接数，别把数据库搞崩
但连接池不