MySQL连接池爆满排查与调优：从根因到解决方案

1. 先看现象连接池爆满到底是什么状态搞后端的人大概率都撞过这种场景某个工作日上午线上突然大量接口超时紧接着监控面板上数据库连接数的曲线像心电图一样一路拉平应用日志里飘着Connection is not available, request timed out、HikariPool-1 - Connection is not available或者 Druid 的wait millis 10000, active 50, maxActive 50这类报错。登录到 MySQL 一查进程列表几百个Sleep连接挂在那边CPU 和内存倒不一定高但新的请求就是进不来。这就是连接池爆满。说白了应用和 MySQL 之间的可用连接被耗尽后续请求拿不到连接只能排队等待排到超时就直接抛异常。先说清楚一个容易混淆的点连接池爆满不等于 MySQL 挂了。很多时候 MySQL 进程活着主从同步正常磁盘 IO 也不算高但应用就是无法访问。因为业务线程卡在“借连接”这一步根本走不到执行 SQL 的环节。所以排查的时候第一反应不应该是重启数据库而应该先确认连接是被谁占着、占了多少、是活跃还是空闲。从应用侧看爆满的直接感受是接口 RT 飙升错误率上升特别是那些首次申请连接就超时的请求会快速失败。而从 MySQL 侧看Threads_connected通常已经逼近甚至达到了max_connections的阈值。这两个信号基本可以锁定方向。还有一个常见的错觉连接池最大连接数设了 50MySQL 的max_connections设了 200为什么还爆因为爆满通常不是总量问题而是某个 Pool 实例的局部问题。一个服务有多个数据源、多个连接池实例时任何一个出问题都会表现为局部接口不可用这时候去调 MySQL 的max_connections是治标不治本真正要查的是那个池子里的连接为什么一直借不到。2. 爆满背后的四类根因连接池爆满绝大多数不是“池子设小了”这么简单。我经手过的案例里真正因为纯容量不够而爆的不到三成剩下的基本都能归结到四类问题。2.1 连接泄漏借出去不还的大头连接泄漏的意思是业务代码从连接池取得连接后因为某个异常路径没有走到close()或者框架里的事务没有正确提交/回滚导致连接一直无法归还到池子里。这类问题最典型的特征是连接池的activeCount持续增长MySQL 侧看到大量Sleep状态连接而应用线程堆栈里却找不到对应的业务执行。我之前排查过一个模拟的订单服务Druid 连接池设为 50上线后每天固定下午三点左右开始报连接池满。看监控发现从中午开始active数量就异常攀升重启后又能撑大半天。后来抓线程堆栈对齐时间点定位到某条分支逻辑里用了Transactional但内部有个try-catch吞掉了异常事务没有正确回滚导致连接一直被事务上下文持有。这种问题最阴险的地方在于它只会在特定异常场景下触发平时压测很难复现。泄漏的另一个常见来源是手动获取连接后忘记释放常见的写法比如Connection conn dataSource.getConnection(); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(sql); // 处理结果但没有 finally 里关闭这种代码在正常路径下没问题一旦中间抛出异常close()永远执行不到。正确做法要么用try-with-resources要么在finally里逐个关闭rs、stmt、conn顺序还不能反。2.2 慢SQL与长事务把连接焊死在事务里长期占用连接比泄漏更难发现因为它“占着坑但看起来正常”。如果一条 SQL 跑了 30 秒还没完对应的连接会一直处于活跃状态期间这个连接无法被其他请求使用。如果连接池只有 20 个连接同一时间进来 20 条慢查询后续所有请求都只能排队。长事务的问题更隐蔽。事务开启后即使执行完所有 SQL 没提交连接也会一直被事务绑定。比如在事务里调了外部接口、做了耗时很长的计算、甚至只是代码逻辑写岔了没有及时 commit都会导致连接被占住。诚然这类代码从“占用时间”看是合理的但从资源利用角度就是灾难因为并发一大池子瞬间就被占满了。我曾经接手的另一个案例更有意思业务高峰期连接池报警但看processlist时没有一条 SQL 执行时间超过 1 秒所有连接都是Sleep状态。后来又对比了事务提交频率发现是某个定时任务批量处理数据时开启了显式事务但一批数据要跑几分钟期间整个连接一直挂起不执行 SQL 但也不释放。2.3 洪峰流量与池容量不匹配这类问题最直接默认配置扛不住突发流量。比如很多框架默认连接池最大连接数只有 10日常 QPS 几百没问题但遇到秒杀、热点事件、定时任务集中触发同一瞬间大量请求同时申请连接池子就爆了。难点在于池容量不是越大越好。很多人一看到爆满就想着调大maximumPoolSize从 50 调到 200。但连接池是有开销的每条连接都要占用 MySQL 端的内存和文件描述符TCP 握手和认证也要耗时。连接数太大还会拖慢数据库的整体响应反而加剧问题。这里更需要关注的是一组关系应用能同时处理多少请求、数据库能同时稳定执行多少 SQL、连接池该配多大才能承接住而不成为瓶颈。一般来说池子大小应该略大于“活跃请求并发数”而不是等于“最大连接数”。如果实际并发请求量远高于池上限要么削峰要么扩容而不是指望连接池硬扛。2.4 连接池参数本身就没配置好这一项属于“配置不当导致的慢性死亡”问题发生时不一定立刻爆但一旦流量有波动就暴露。最常见的几类连接池最大连接数设置过小比如 10、20完全跟不上业务并发。空闲连接回收时间过长或根本没配置池里保留了大量闲置连接MySQL 端wait_timeout已将其断开但应用不知道拿到手才发现连接已失效。connectionTimeout请求连接池的等待时间配置过长比如 30 秒导致请求集体排队后体感是被“卡死”用户侧表现为超时报错服务端线程全在等待。初始化连接数设得很大应用启动时一次性建立大量连接给 MySQL 造成连接风暴反过来影响了启动速度。还有一个经常被误解的参数是maxLifetime。它表示连接的最大存活时间超过这个时间连接会被主动淘汰重建。如果这个值比 MySQL 的wait_timeout还大连接在池子里活得好好的但 MySQL 那边早就把它断掉了。等到业务请求拿到这种“假连接”执行第一条 SQL 就会报通信故障然后触发重新连接重连期间如果请求量大连接池会短暂出现借不到连接的情况。3. 一套能落地的排查流程遇到连接池爆满最忌讳的是上来就重启应用或者调大参数。重启确实能清空连接池但问题没找到下次还会爆而且有些连接是长事务状态重启应用会导致事务被强制中断数据一致性可能出问题。常规思路应该按照“服务端确认 - 应用侧取证 - 日志定位 - 临时止血”的顺序来。3.1 服务端快照先看 MySQL 眼里谁在占用第一步先登录 MySQL跑几条命令确认当前连接概况-- 查看当前线程连接数 SHOW STATUS LIKE Threads_connected; SHOW STATUS LIKE Threads_running; -- 查看最大连接数配置 SHOW VARIABLES LIKE max_connections; -- 查看当前所有连接详情 SELECT id, user, host, db, command, time, state, LEFT(info, 200) AS sql_text FROM information_schema.processlist ORDER BY time DESC;需要重点看的信息有三块Command字段是Sleep还是QueryTime字段的大小State字段的具体内容。如果大量连接的Command是Query且Time很大说明有慢 SQL 或死锁等特殊状态。如果大量Sleep连接且Time几十秒甚至几分钟那就要怀疑连接泄漏或者事务未提交尤其在连接数持续攀升的情况下。这里有一个小技巧不要只查SHOW FULL PROCESSLIST默认输出可能被截断后面的 SQL 文本看不全。用information_schema.processlist配合LEFT(info, 200)可以控制显示长度既能看到开头片段又不至于刷屏。另外可以顺手看一眼 InnoDB 的锁等待状态排除死锁导致的互相等待SELECT * FROM sys.innodb_lock_waits\G SELECT * FROM performance_schema.data_lock_waits\G如果有锁等待进程列表里也能看到对应的连接状态是Waiting for table metadata lock或者行锁等待相关提示。3.2 应用侧取证哪个线程在借连接服务端能看到连接从哪来但看不到应用内部是谁借了连接不还。这时候需要在应用侧抓线程堆栈。以 Java 为例使用jstack抓取堆栈时重点看http-nio-exec-*、业务线程池和执行定时任务的线程名称。如果它们大量停在以下位置就能说明问题停在java.sql.DriverManager.getConnection或连接池的connection获取逻辑说明线程在排队等连接。停在 JDBC 驱动的执行方法上且堆栈下面跟着具体的 SQL 执行片段说明连接已经被这个线程持有并在执行 SQL。停在事务提交或回滚相关的方法说明事务结束阶段耗时异常或有锁等待。更有效的做法是连续抓两份堆栈间隔 5 到 10 秒对比期间线程状态有没有变化。如果一批线程一直停在同一个位置大概率是卡死在某个外部依赖上如果线程状态在变化但连接始终不归还那就更接近连接泄漏。HikariCP 还提供了一个方式开启leakDetectionThreshold参数。当连接借出时间超过阈值会打印一条警告日志带上堆栈信息。这个参数强烈建议在压测或排查期间打开线上可以配合 Sampling 方式降低性能影响。Druid 连接池也有类似能力removeAbandonedtrue配合removeAbandonedTimeoutMillis但生产环境要谨慎自动回收有可能中断正在执行的慢 SQL反而引发数据问题。3.3 关键日志与监控指标连接池爆满的排查通常离不开监控历史。有监控平台自然方便没有的话至少要把以下指标收集起来MySQL 侧Threads_connected、Threads_running、Max_used_connections、Aborted_connects、慢查询数量。应用侧连接池的活跃连接数、空闲连接数、等待申请连接数、等待超时次数。业务侧接口 P99 耗时、错误率、QPS。排查时优先关注时间线对齐。连接数是从几点开始涨的涨之前发生了什么是上线了代码还是流量突增还是某个定时任务触发了把监控曲线和发布记录叠在一起看往往几分钟就能圈定方向。慢查询日志也要第一时间打开即使平时没开排查期间临时开启并配合long_query_time1或者更小观察一段时间能抓到很多平时例行压测发现不了的问题。SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;需要注意在已有压力的情况下开启慢日志日志文件膨胀会很快建议指定合理的slow_query_log_file并定期轮转不要让它无限写下去。3.4 临时止血与逐步放量定位期间如果业务已经严重受损要做的是先止血而不是等完整根因。一个相对安全的操作是把连接池的maximumPoolSize临时调大一些前提是 MySQL 的max_connections还有余量且数据库负载不高。这个操作应用可以直接热配置生效比如 HikariCP 基于动态代理可以修改maximumPoolSize后调用HikariCP相关接口使其生效Druid 也支持动态调整。但注意调整最大连接数只是让问题表象缓解不能解决导致连接占用的根因。如果连接数是持续攀升而不是稳定在某个水平调大连接数只会推迟爆满的时间点最终还是会爆。如果确认是连接泄漏还可以考虑临时开启 Druid 的removeAbandoned或者 HikariCP 的leakDetectionThreshold先让异常连接被强制回收保住服务。不过要评估一下业务是否能容忍这种强杀连接带来的不确定性比如事务中途被断可能会造成部分操作未完成。4. 解决办法与参数调优连接池爆满的解决方案本质上是三件事让连接正常归还、让池子大小合理、让数据库扛得住。对应到落地层面就是代码修复、参数调整、容量规划。4.1 代码层修复连接泄漏代码层的排查要精确到具体位置。常见的修复手段包括所有手动获取的连接一律放进try-with-resources或finally块中关闭。使用框架的事务管理时确保异常不外泄或不被盲目吞掉必要时手动setRollbackOnly。避免在事务中执行远程调用、IO 等待等耗时操作把非数据库操作移出事务。使用连接池自带的连接借用监控把泄漏的调试点暴露出来。还有一个经常被忽略的修复点多数据源事务。如果业务里用到了多个数据源而且启用了 JTA 分布式事务事务生命周期会横跨多个连接一个事务卡住影响的是多个池子。这种场景下哪怕只是某条 SQL 慢也会导致多个数据源连接同时被释放不掉。4.2 连接池参数推荐与计算方式以下以 HikariCP 为例但核心思路对所有连接池通用。先理解几个关键参数参数作用常见误区minimumIdle维持的最小空闲连接数设得太大空闲时浪费数据库资源maximumPoolSize最大连接数追求大而忽略了数据库承受能力connectionTimeout等待获取连接的超时时间太长导致请求排队堆积idleTimeout空闲连接回收时间大于等于maxLifetime会产生冲突maxLifetime连接最大存活时间大于 MySQLwait_timeout会拿到失效连接leakDetectionThreshold连接泄漏检测阈值太小容易误报一个基础的计算思路是先估算业务高峰期需要的并发数据库操作数。比如某服务高峰期有 200 个请求线程其中 25% 会执行数据库操作那同时执行数据库操作的请求大约 50 个。连接池大小可以先设为 50再结合 MySQL 的负载表现调整。注意连接池大小还要考虑每个连接在 MySQL 端的开销。经验上单实例 MySQL 的连接数控制在 200 以内比较安全当然这要看实例规格。如果业务连接数需求远超数据库承受力优先考虑拆分服务、增加只读实例、引入缓存而不是硬调连接池。推荐的初始参数参考spring.datasource.hikari.minimumIdle10 spring.datasource.hikari.maximumPoolSize50 spring.datasource.hikari.connectionTimeout3000 spring.datasource.hikari.idleTimeout600000 spring.datasource.hikari.maxLifetime1800000 spring.datasource.hikari.validationTimeout1000这里的connectionTimeout设的是 3 秒意味着拿不到连接最多等 3 秒超出即失败。这个值不能设得太长否则高峰期所有请求都会堆在获取连接这一步线程被占住服务反而更容易雪崩。maxLifetime设为 30 分钟比 MySQL 默认的wait_timeout通常 8 小时短可以确保连接被 MySQL 断开前由应用主动淘汰。Druid 场景下等价参数是spring.datasource.druid.initial-size10 spring.datasource.druid.min-idle10 spring.datasource.druid.max-active50 spring.datasource.druid.max-wait3000 spring.datasource.druid.validation-querySELECT 1 spring.datasource.druid.test-while-idletrue4.3 MySQL 侧参数配合连接池参数不是孤立存在的。MySQL 侧的max_connections、wait_timeout、interactive_timeout都会直接影响连接的可用性。如果应用连接池的maxLifetime大于 MySQL 的wait_timeout会出现拿到“半死连接”的情况。MySQL 默认wait_timeout是 8 小时HikariCP 默认maxLifetime是 30 分钟这组默认值本身没冲突。但很多运维同学会把wait_timeout调小来清理空闲连接比如改成 60 秒或 300 秒同时没有同步调应用的maxLifetime就容易出问题。建议先检查两边配置原则是MySQL wait_timeout 连接池 maxLifetime 连接池 maxLifetime idleTimeout一旦发现顺序错了优先调整应用侧而不是数据库侧。因为应用侧主动回收连接是平滑的数据库侧被动断开可能导致应用出现短暂的通信故障。max_connections的调整要更加谨慎。它保护的是数据库实例的整体稳定性。如果连接请求数量超过max_connectionsMySQL 会直接拒绝新的连接抛出Too many connections这种拒绝是物理层面的比连接池超时更严重。线上一般不要轻易调大除非已经确认数据库实例规格有足够冗余且相关服务确实需要更多连接。4.4 长期治理与容量规划参数调整之后长期要做的是三件事监控、巡检、压测。监控层面连接池活跃数、等待数、MySQL 线程数、慢查询数必须上线告警。阈值设置可以参考历史数据比如连接池使用率超过 80% 持续 5 分钟告警或者等待获取连接的次数超过每分钟 10 次就告警。巡检层面定期检查连接池配置和 MySQL 配置的匹配情况maxLifetime、idleTimeout、wait_timeout三者是否合理对齐maximumPoolSize是否和数据库实例规格匹配有没有新增数据源但配置沿用默认值的情况。压测层面每次发版本前做一次小流量压测重点观察连接池指标。不需要追求很高的 QPS关键是能看到连接池的活跃数曲线是否平滑、是否存在持续攀升的趋势。如果曲线在压测结束后不能回落说明大概率有泄漏需要尽快定位。防患于未然的另一个角度是给连接池预留缓冲。比如实际业务峰值并发 30连接池最大可以设到 50留出一部分余量应对瞬时波动。但前面也说了余量不能无限放大池子太大本身也会带来开销。5. 我踩过的坑和复盘案例5.1 一次典型的“连接池爆满”排障过程某次线上一个订单查询服务突然告警错误率从 0.2% 跳到 30%。登录 MySQL 一看Threads_connected已经到了 300而max_connections是 500看起来还有余量但服务已经大面积超时。查连接池监控发现两个数据源中有一个池子的activeCount已经接近最大值另一个池子还算正常。先用information_schema.processlist查了当时连接分布除了日常的查询连接发现了一批CommandSleep、Time超过 10 分钟的空闲连接数量还在增长。这就不是慢 SQL 的问题了更像是有人借了连接不还。抓了应用线程堆栈看到很多线程阻塞在连接池的等待获取逻辑说明池子确实被占满了。用jstack连续抓了几份找到有少量线程停在一个Async方法里里面有手写的 JDBC 操作并且没有关闭连接。代码定位后确认是某次需求迭代加了个异步导出功能里面用了原生 JDBC结果漏写了close()。代码 review 时没注意到压测时功能没有被覆盖到。修复方法很简单把连接获取改成try-with-resources重新发布后连接数曲线逐步回落问题解决。这次排障花了大约两小时前面一大半时间浪费在反复调参数、重启上直到想到抓线程堆栈才看到真凶。5.2 复盘时容易被忽略的细节连接池爆满的问题复盘时最容易犯的错是“修复了表象就算完”。比如只调大了连接池参数下个流量波峰又出问题或者只杀掉了某个连接泄漏但没排查其他代码路径是否有类似问题。复盘时我会特别检查这几个点是否有其他服务或数据源共用同一个 MySQL 实例连接数的增长是不是其他服务引起的。是否有定时任务集中在整点触发造成连接瞬间被占满。如果有建议分散触发时间。是否存在跨服务调用链路上游超时会连带导致数据库连接被长时间占用。连接池状态变化趋势是否已经纳入监控避免下次问题复现时没有依据。还有个小细节排查时很容易忽略wait_timeout和max_connections是全局参数而不是针对某个连接的。如果 MySQL 上跑着多个业务一个业务的连接池配置混乱会拖累其他业务。这种情况在逻辑隔离的环境里不明显但因为共享实例一旦一个池子把连接耗尽其他服务会跟着遭殃。建议在架构允许的情况下不同业务尽量使用不同实例或在 MySQL 侧做账号和连接数级别的限制。5.3 日常预防的几条实用建议最后说几条对我来说性价比极高的预防手段可能不复杂但非常管用。第一是给连接池加泄漏检测。HikariCP 把这个阈值设置在 30 秒到 60 秒比较合理太短会误报太长意义不大。这个参数平时开着不会有明显性能损耗排查时能省去大量猜测工作。Druid 的removeAbandoned建议先不开用logAbandonedtrue只记录不回收确认有泄漏再开强回收。第二是慢查询日志常开但可以设置一个合理的阈值。线上可以开到long_query_time2如果担心日志增长过快只对特定库开启或者定期轮转即可。慢查询日志能直接揭示哪些 SQL 在高峰期拖住连接是定位问题的第一手材料。第三是建立连接池相关告警时不要只盯最大连接数的使用率要同时关注“获取连接等待次数”。等待次数开始增长往往比活跃数接近上限更早出现。把等待次数告警和活跃数告警组合起来能提前预警很多连接池隐患。第四是在发布流程中加入连接池配置 review特别是新增数据源、多数据源切换这类改动。拿一段对比检查的时间避免上线后才发现新数据源的参数完全没配。最后一件事连接池爆满这类问题说到底是资源管理的问题而资源管理最怕的就是等到触顶才动手。我个人的感受是MySQL 连接池的调优更像“先保证不爆再优化性能”如果不在代码和监控层面把连接的生命周期管住参数再怎么调也只是在推迟下一次事故。每次排完这类问题我都会顺手把过程记录成一份存档包括时间线、现象、根因、修复动作和监控截图。时间久了翻出来看很多看似巧合的现象其实都有规律可循提前埋下的监控项也会在下一次问题来临前发出预警。这个习惯比任何一次紧急排障都有价值。