连接池调完就完事了？监控与动态调优实战

微信图片_2026-06-18_113638_515.png

去年一个客户，大促前调优了连接池，把最大连接数从50调到200，自信满满。大促当天，连接池还是爆了。查了半天，不是连接数不够，是业务代码里有个慢查询，把连接占住了不释放。连接池再大，也扛不住连接被长期占用。

这是连接池管理最容易被忽视的问题：配置只是起点，持续监控才能发现问题。

01 配置会“过期”

很多人以为连接池配一次就完事了。但业务在变，流量在变，数据库也在变。

连接池配置不是“设完就忘”，要持续观察、持续调整。

那家客户的连接池爆了，不是因为池太小，是因为慢查询让连接持有时间从50ms涨到3秒。同样的并发量，需要的连接数翻了几十倍。如果只看连接数监控，会误以为池不够大，继续加大反而让数据库压力更大。

不是所有指标都要看。盯住这四个。

活跃连接数（activeCount）

当前正在使用的连接数。接近maximumPoolSize时，说明连接池快饱和了。但高不一定是池不够，也可能是连接持有时间变长了，或者有慢查询占着不放。如果活跃连接数持续超过最大值的80%，就值得警惕了。

等待线程数（threadsAwaitingConnection）

有线程在排队等连接，说明连接不够用。持续大于0超过几分钟，需要排查原因。当活跃连接数接近最大值时，新请求就会开始排队，系统响应时间会飙升。

连接获取耗时（acquireTime）

从请求连接到拿到连接的时间。正常几毫秒，突然变长说明连接池紧张了。建议将connectionTimeout设置为1-3秒，让请求快速失败而不是一直卡着。如果获取耗时持续增加，往往是连接泄漏或慢查询的前兆。

连接泄漏检测

HikariCP的leakDetectionThreshold设成2-3秒。超过阈值没归还，打印堆栈日志，直接定位到没关连接的代码。不少系统就是因为漏了finally块里关闭连接的代码，连接池慢慢被耗尽，问题潜伏几周才爆发。

告警不是越早越好，要避免误报。

告警一：活跃连接 > 80% maximumPoolSize，持续5分钟

偶尔高是正常的流量波动，持续高说明有趋势。收到告警先看获取耗时和慢查询日志，别急着调大连接数。云厂商的智能运维工具（如DBbrain）会在连接池使用率超过阈值时触发告警，提前干预。

告警二：等待线程 > 0，持续3分钟

有线程在等连接，说明已经有人开始卡了。这是高风险告警，需要立即排查：看慢查询、看连接持有时间、看是不是有连接泄漏。

告警三：连接获取耗时 > 100ms，持续2分钟

获取连接变慢是连接池压力的早期信号。还不用半夜爬起来，但需要白天排查。

那家客户后来配了这三条告警。下次慢查询出现时，他们在获取耗时告警阶段就发现了问题，在用户感知到超时之前就修复了。

有些连接池支持动态调整，但不是开了就行。

HikariCP没有自动调大功能。要手动评估后调整。可以先调整连接获取超时（connectionTimeout），让线程快速失败，不排队堵死，再排查根因。

Druid支持动态调整，可以通过JMX修改参数，不用重启应用。但动态调整是辅助手段，根因排查才是根本。

云数据库智能运维：腾讯云DBbrain等工具可以自动分析连接池状态，给出扩容建议或自动调整参数。

那家客户没有依赖自动扩容，而是先修复慢查询。连接持有时间降下来后，连接数自然够了。自动扩容不能解决连接持有时间长的问题，扩容到1000个连接，数据库可能先撑不住了。连接池大小建议参考CPU核心数×2+磁盘数的公式，过大的连接池反而会导致上下文切换频繁，降低性能。

Grafana面板上放这几个图：

Druid自带的监控页面提供了SQL执行时间分布、读取行数等详细指标，可以帮你发现隐藏的N+1查询问题——某个接口的读取行数是执行次数的100倍，明显存在循环查询数据库的情况。

那家客户把连接池监控放到运维大屏上。以前是“出了问题才看”，现在每天扫一眼趋势，提前发现问题。

一个SaaS客户，连接池突然爆满。监控显示活跃连接数持续100%，等待线程几十个。查了连接池配置，参数没问题。

看了慢查询日志，发现一个SQL从50ms涨到2秒。原因是数据量增长，原来的索引不够用了。加了索引后，SQL回到50ms，活跃连接数从100%降到30%。

运维负责人说：“以前觉得连接池问题就调连接数，现在学会了，先看连接持有时间，再看慢查询。”

连接池配好了，监控要跟上。配置是静态的，业务是动态的。

那家客户的运维负责人后来总结：“四个指标盯住了：活跃连接数、等待线程、获取耗时、泄漏检测。告警要分级别，先看持有时间再看慢查询，别急着调大连接数。”

你的连接池监控，配了吗？