连接池调完就完事了？监控与动态调优实战
去年一个客户，大促前调优了连接池，把最大连接数从50调到200，自信满满。大促当天，连接池还是爆了。查了半天，不是连接数不够，是业务代码里有个慢查询，把连接占住了不释放。连接池再大，也扛不住连接被长期占用。
这是连接池管理最容易被忽视的问题：配置只是起点，持续监控才能发现问题。
01 配置会“过期”
很多人以为连接池配一次就完事了。但业务在变，流量在变，数据库也在变。
业务增长后，原先合适的池大小可能变成瓶颈
代码改动引入慢查询，连接持有时间变长
数据库迁移后，响应时间变化影响连接周转
连接池配置不是“设完就忘”，要持续观察、持续调整。
那家客户的连接池爆了，不是因为池太小，是因为慢查询让连接持有时间从50ms涨到3秒。同样的并发量，需要的连接数翻了几十倍。如果只看连接数监控，会误以为池不够大，继续加大反而让数据库压力更大。
02 关键监控指标
不是所有指标都要看。盯住这四个。
活跃连接数（activeCount）
当前正在使用的连接数。接近maximumPoolSize时，说明连接池快饱和了。但高不一定是池不够，也可能是连接持有时间变长了，或者有慢查询占着不放。
等待线程数（waitingThreads / threadsAwaitingConnection）
有线程在排队等连接，说明连接不够用。持续大于0超过几分钟，需要排查原因。
连接获取耗时（acquireTime）
从请求连接到拿到连接的时间。正常几毫秒，突然变长说明连接池紧张了。这个指标比活跃连接数更能提前发现问题——等到活跃连接数满了，用户已经开始超时了。
连接泄漏检测
HikariCP的leakDetectionThreshold设成2-3秒。超过阈值没归还，打印堆栈日志，直接定位到没关连接的代码。
03 告警怎么设
告警不是越早越好，要避免误报。
告警一：活跃连接 > 80% maximumPoolSize，持续5分钟
偶尔高是正常的流量波动，持续高说明有趋势。收到告警先看获取耗时和慢查询日志，别急着调大连接数。
告警二：等待线程 > 0，持续3分钟
有线程在等连接，说明已经有人开始卡了。这是高风险告警，需要立即排查：看慢查询、看连接持有时间、看是不是有连接泄漏。
告警三：连接获取耗时 > 100ms，持续2分钟
获取连接变慢是连接池压力的早期信号。还不用半夜爬起来，但需要白天排查。
那家客户后来配了这三条告警。下次慢查询出现时，他们在获取耗时告警阶段就发现了问题，在用户感知到超时之前就修复了。
04 动态调优不是自动的
有些连接池支持动态调整，但不是开了就行。
HikariCP没有自动调大功能。要手动评估后调整。可以先调整连接获取超时（connectionTimeout），让线程快速失败，不排队堵死，再排查根因。
Druid支持动态调整，可以通过JMX修改参数，不用重启应用。但动态调整是辅助手段，根因排查才是根本。
云数据库智能运维：腾讯云DBbrain等工具可以自动分析连接池状态，给出扩容建议或自动调整参数。
那家客户没有依赖自动扩容，而是先修复慢查询。连接持有时间降下来后，连接数自然够了。自动扩容不能解决连接持有时间长的问题，扩容到1000个连接，数据库可能先撑不住了。
05 监控仪表盘长什么样
Grafana面板上放这几个图：
活跃连接数 vs 最大连接数：看还有多少余量
等待线程数：0是正常状态
连接获取耗时趋势：变陡说明有问题
连接泄漏日志：抓取超过阈值的堆栈
那家客户把连接池监控放到运维大屏上。以前是“出了问题才看”，现在每天扫一眼趋势，提前发现问题。
06 一个真实案例：慢查询偷走连接
一个SaaS客户，连接池突然爆满。监控显示活跃连接数持续100%，等待线程几十个。查了连接池配置，参数没问题。
看了慢查询日志，发现一个SQL从50ms涨到2秒。原因是数据量增长，原来的索引不够用了。加了索引后，SQL回到50ms，活跃连接数从100%降到30%。
运维负责人说：“以前觉得连接池问题就调连接数，现在学会了，先看连接持有时间，再看慢查询。”
写在最后
连接池配好了，监控要跟上。配置是静态的，业务是动态的。
那家客户的运维负责人后来总结：“四个指标盯住了：活跃连接数、等待线程、获取耗时、泄漏检测。告警要分级别，先看持有时间再看慢查询，别急着调大连接数。”
你的连接池监控，配了吗？
