数据库连接池打满：应用侧的排查

发布时间:2026-01-27 08:40

## 症状 应用日志突然刷出获取连接超时的报错，接口大面积变慢甚至失败，数据库本身的连接数曲线顶到了应用配置的上限。重启应用后恢复一阵，几个小时后又满，业务量并没有明显增长，问题像是从天上掉下来的。 ## 定位 先分清是数据库慢还是连接被占着不放。看数据库侧的活跃连接与等待状态：大量连接处于空闲或长事务状态，说明是应用侧的连接泄漏；全部连接都在忙碌执行，则要回头查慢查询。抓一段连接的来源与存活时间。 ``` SHOW PROCESSLIST; ``` 同一来源的连接存活时间越来越长、数量只增不减，泄漏特征成立。连接泄漏的典型代码路径：异常分支里没有归还连接，长事务里夹着外部调用把连接拖住，连接池配置的最大数远超数据库能承载的总量。 ## 解决 泄漏类问题的修复在应用代码：用框架托管连接的生命周期，确保任何分支都会归还；外部调用移出事务范围，缩短连接占用时间。临时缓解可以调大池子上限，但要先确认数据库的总容量撑得住，单纯放大池子只是把超时挪了个位置。配置层面把池子的最大数、最大存活时间、空闲回收时间三件事一起定好，让连接有进有出。 ## 预防 把连接池的活跃数、等待线程数、等待时间纳入应用监控，这三项比数据库连接总数更早暴露问题。压测场景里专门设计异常路径，验证连接在异常时也能归还。池参数与数据库容量放在一起评审，任何一侧单独调整都可能打破平衡。顺云云服务器上数据库与应用的容量配比定好后写进部署文档，扩容应用实例时同步复核连接总数预算，避免多实例叠加把数据库顶穿。