一次数据库连接池被打满的故障排查纪实：程序员生涯中印象最深的Bug

在程序员的职业生涯中，总有几个深夜或紧急工单让人记忆犹新。而那次支付服务数据库连接池被打满的事故，至今仍是我技术履历里最深刻的一课。它不仅考验了临场排障的冷静，更暴露了系统设计中那些容易被忽视的”蚁穴”。今天，我想完整还原这次事故的来龙去脉，并分享从中提炼出的通用排查方法论。

事故初现：运营反馈与第一反应

那是一个寻常的工作日下午，运营同事急匆匆地跑过来说：”很多用户反馈支付不了，页面一直转圈，最后报错。”

这是一个运行多年的老支付服务，代码经历了至少三任开发者的维护，长期稳定，几乎没有出过大的线上故障。接到消息后，我的第一反应是查看服务器日志。果不其然，日志里刷满了同一种异常：Data source rejected establishment of connection, message from server: "Too many connections"。

数据库连接数被打满了。这是典型的资源耗尽型故障。由于支付链路至关重要，当时容不得半点犹豫——我立刻联系运维，对支付服务的两个节点执行了重启操作。这是最快速止血的手段，几分钟后，服务陆续恢复，用户支付流程暂时恢复正常。

初步排查：连接泄漏？还是连接池配置问题？

服务恢复了，但根因未除，就像一颗定时炸弹还在滴答作响。我首先怀疑的是经典的”连接泄漏”问题——即代码中获取了数据库连接后，在某些异常分支没有正确释放，导致连接被耗尽。

我快速翻阅了服务中所有涉及数据库操作的代码段，重点检查了try-catch-finally块以及使用了ORM框架的Repository层。令人失望的是，代码逻辑层面并未发现明显的连接未关闭问题。我们使用的是一款主流的数据库连接池组件，它本身具备空闲连接回收机制，理论上即使有少量连接被长时间占用，也会在达到idleTimeout后被回收。因此，”连接泄漏”这个假设被暂时排除。

就在这时，监控告警再次响起——另一个节点也出现了”Too many connections”错误。这意味着问题仍在蔓延，单纯的节点重启治标不治本。

应急扩容：修改最大连接数

既然应用代码层面暂未发现问题，那么瓶颈可能出现在数据库端。我们当时的数据库最大连接数配置为500。考虑到支付服务有多个节点，每个节点连接池默认初始化了50个连接，上限是100，理论峰值确实可能逼近数据库端的500上限。但为什么以前没出问题，偏偏今天爆发？

为了争取更多的排查时间，我决定先临时调整数据库的最大连接数。执行以下命令：

-- 全局生效，不需要重启MySQL实例
SET GLOBAL max_connections = 1000;

这条命令能立即生效，虽然无法解决根本问题，但至少为后续的深入分析提供了喘息之机——新的连接可以进来了，不至于让服务立刻陷入瘫痪。

深入诊断：SHOW PROCESSLIST 与隐藏的慢查询

连接数扩大后，我立刻联合DBA团队进行根因分析。首先使用的工具就是MySQL的SHOW PROCESSLIST命令。这条命令能列出当前所有活跃的连接线程及其正在执行的SQL语句、状态、耗时等信息。

SHOW FULL PROCESSLIST;

观察输出结果后，我们发现了几个关键异常点：

1. 大量连接处于Sleep状态：这些连接并非在执行查询，而是空闲等待。但令人费解的是，按照连接池的配置，空闲连接应该被回收，这里却堆积了大量未被回收的连接。
2. 部分连接处于Query状态且Time值很高：有几条SQL语句的执行时间超过了30秒。这些慢查询主要集中在几个特定的业务表上，且SQL写法存在明显的性能隐患——使用了非索引字段作为WHERE条件，或者对大量数据进行JOIN操作。

这下，问题逐渐清晰了。慢查询长时间持有数据库连接，导致连接池中的连接无法及时归还给连接池复用。而连接池在检测到活跃连接数超过阈值时，会持续创建新连接以应对新的请求，直到达到数据库端的max_connections上限。一旦达到上限，新的请求再也无法获取连接，从而抛出了”Too many connections”异常。

根因剖析：连接池参数与流量突增的共振

为什么以前没有爆发，偏偏今天爆发？进一步分析后，我们发现这是一次典型的三重因素叠加：

第一重：连接池的maxLifetime与数据库的wait_timeout配置不匹配。 数据库端的wait_timeout默认是8小时，而连接池的maxLifetime如果设置得比数据库的wait_timeout长，数据库会主动断开空闲连接，但连接池并不知道，仍然保留着这些”半死”的连接引用。当新请求到来时，连接池尝试使用这些已失效的连接，需要额外的时间去验证和重建连接，导致连接获取延迟，进而促使连接池快速膨胀。

第二重：存在未被索引覆盖的慢查询。 在当天的业务高峰期，某个促销活动带来了大量并发查询。这些查询命中了慢SQL，每一条都持有连接超过数十秒，导致连接周转率急剧下降。

第三重：应用层未配置连接池的等待队列长度。 当连接池所有连接都被占满时，新的请求本该进入一个有限的等待队列。但我们的连接池配置中，maxWait参数设置得过大，导致大量请求线程阻塞在获取连接上，进一步加剧了线程资源的消耗，甚至引发了应用服务器的线程池饱和。

系统性修复：不只解决表面症状

找到根因后，我们进行了三个维度的修复：

1. SQL性能优化

针对慢查询，我们进行了执行计划分析，为高频查询涉及的WHERE条件字段和JOIN字段添加了联合索引。同时，将部分复杂的实时统计查询改为异步预计算的模式，避免在业务高峰期直接查询大表。

2. 连接池参数调优

我们对连接池配置进行了体系化调整：

• 将maxLifetime设置为略小于数据库wait_timeout的值，确保连接池能主动淘汰被数据库断开的连接。
• 设置了合理的minIdle与maxActive比例，避免连接数在空闲时过度收缩，导致突发流量时频繁建连。
• 设置了明确的maxWait值（例如3秒），当连接获取超时直接抛出异常，而不是无限期阻塞，保护应用线程池不被拖垮。

3. 引入数据库连接耗尽监控与自愈机制

除了参数调整，我们还上线了更完善的监控指标：

• 监控活跃连接数（Threads_connected）与连接池使用率，当使用率超过80%时触发告警。
• 配置了自动化的慢查询日志分析工具，定时扫描并推送新出现的慢SQL至开发群。
• 在应用侧增加了连接池的健康检查机制，定期发送心跳SQL（如SELECT 1）验证连接有效性。

复盘总结：给后来者的几点建议

这次事故虽然惊险，但收获巨大。复盘时，我总结了以下几点经验，希望能给各位同行带来启发：

1. 永远不要只做”重启”这一层止血。重启只能解决进程内部状态问题，对资源耗尽型故障必须追问到数据库层和网络层。
2. 连接池参数不是一成不变的默认值。它必须与底层数据库的wait_timeout、max_connections以及应用自身的QPS模型匹配。建议在压测环境中模拟极限流量，找到参数组合的最优解。
3. 警惕慢查询的多米诺效应。一条慢SQL在低并发时可能只是响应慢一点，但在高并发下它会占满连接池，拖垮整个服务。定时巡检慢查询日志应当是运维的日常功课。
4. 建立故障应急手册。针对数据库连接耗尽这类常见故障，应提前制定好检查清单：先看PROCESSLIST，再看连接池状态，再查慢查询，最后调整容量。有了手册，即使是初级开发也能快速上手止血。

那次事故之后，支付服务再也没有出现过类似问题。但这段经历始终警醒着我：在分布式系统里，最不起眼的连接池往往是最脆弱的枢纽。只有对每一个参数、每一条SQL都怀有敬畏之心，才能真正构建出高可用的服务。希望这篇记录能让你在面对类似问题时少走一些弯路。