公司业务半夜报警，数据库连接池直接打满，用着好好的服务突然就“Too many connections”，随后页面超时、接口504，紧接着一堆任务队列堆积告警。这种情况我处理过不止一次，每次原因都不完全相同，但排查思路是共通的。这篇就完整回顾一次连接池爆满的排查过程和修复手段，把每一层的判断逻辑、关键命令、避坑点全部捋一遍。不管你是开发、DBA还是运维，看完都能直接照着这套流程去定位。
先说清楚一个概念，连接池爆满不是数据库本身挂掉，而是“能建立连接的通道”被占满了。就好比酒店前台只有10个接待窗口，所有客人挤在窗口前不走，后面来的人连取号的机会都没有。MySQL 默认的max_connections通常是 151（不同版本略有差异），一旦并发请求同时占用的连接数达到上限，新的连接请求就会直接报错。应用层如果用了 HikariCP、Druid、C3P0 这类连接池，还会叠加一层自己的连接上限，两层限制一起挡住，反应到业务上就是“连接不到数据库”“服务不可用”。
1. 先看现象，再定排查方向
1.1 报错信息反推问题层面
我见过的连接池爆满报错大致分三类，每一类对应的处理起点都不一样。
第一类是中间件报错，比如 HikariCP 抛出Connection is not available, request timed out after 30000ms，或者 Druid 报wait millis 30000, active 200, maxActive 200。这类报错说明应用层连接池已经把所有连接都借出去了，且等待队列里还有请求在排队，30秒没等到空闲连接就超时。问题出在“应用拿不到连接”，但根因可能在应用自身，也可能在数据库端——如果慢SQL把连接长期占住，连接池再大也会被打满。
第二类是数据库端报错，ERROR 1040 (HY000): Too many connections。这是 MySQL 自己到达了max_connections上限，直接拒绝新连接。这时候应用连接池申请新连接也失败，于是应用侧同步触发连接池排队超时。这条报错能确定问题在数据库侧，但数据库侧连接多，有可能是业务流量增长、慢查询堆积、长事务未释放，也可能是排查者自己在命令行连不上去。
第三类最隐蔽，是连接池内核健康但接口还是慢。比如连接池正常，但 MySQL 的 CPU 打满、磁盘IO异常，SQL 执行速度变慢，导致单个连接被占用的时间变长，连接周转率下降，在并发量不变的情况下连接数被慢慢推到高位。这种情况连接池和max_connections都没到上限，但业务感知到的是“数据库越来越慢”，最终也会爆。
拿第三条举例，数据库 CPU 使用率 99% 时，一条原本1毫秒的查询可能变成1秒。如果业务并发是200，连接池上限也是200，每个连接都被慢SQL霸占，新的请求只能在池外排队。池子看似没爆，实际已经“功能性爆满”了。
1.2 一边查一边压——排查命令怎么用
进入服务器终端后，先别急着重启MySQL，重启虽然能临时清掉连接，但根因没找到，过一会儿又会爆。首要任务是抓现场。
连接不上数据库时，先用一个“逃生窗口”登录。MySQL 会给super权限的账号预留一个连接通道，即使max_connections已满，SUPER权限账号依然可以连进去。用 root 或者有SUPER权限的账号执行：
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';" mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"这两个命令分别看当前已用连接数和最大连接数。如果Threads_connected已经贴近max_connections，那就是物理连接被占满。
再看连接都是从哪来、在干什么：
SELECT user, host, db, command, time, state FROM information_schema.processlist ORDER BY time DESC;这个查询把当前所有连接按执行时间倒序排，优先看time特别大的会话。如果发现大量Sleep状态的连接，说明应用拿完连接不释放，或者连接空闲超时时间设置太长；如果大量连接卡在Query状态且time很大，多半是有慢SQL在跑；如果连接数不大但都在Locked状态，要考虑锁等待。
我个人的习惯是第一轮先抓三样东西：processlist、慢查询日志位置、连接数变化曲线。有了这三样，大部分问题能定位到具体范围。
2. 按三层拆解根因——应用层、数据库层、网络层
2.1 应用层：连接泄漏、参数配置、连接池大小
连接泄漏是应用层最常见的爆池原因。所谓泄漏，就是应用从连接池借了连接，用完没有归还。每次请求泄漏1个，在高并发下几分钟内就能把池子填满。代码里常见的泄漏场景有：
- 从连接池获取连接后，在 try 块里执行SQL，但 finally 没有调用
close()； - 使用
TransactionTemplate或者@Transactional时，事务内抛异常但连接未正确释放； - 多线程并发使用同一个
Connection对象，用完只关了一个副本； - 使用
JdbcTemplate查询返回ResultSet后，没有关闭Statement和ResultSet。
排查时重点看连接池的活跃连接曲线。Druid 有监控页面，HikariCP 可以通过HikariPoolMXBean拿到getActiveConnections()和getIdleConnections()。如果活跃连接数持续高位不下降，基本可以断定有代码路径在泄漏连接。还有一个土办法，把连接池的最大连接数调到一个相对小的值，观察报错时应用的线程堆栈，用jstack抓线程，看哪个线程一直持有着连接对象。
应用层参数配置也是重灾区。常见的坑是maximum-pool-size设得过大。很多团队喜欢把连接池上限设成 500、800 甚至 1000，觉得越高越好。实际上连接池越大，数据库侧的max_connections也要跟着调大，连接本身的创建和销毁都有开销。大量空闲连接也会占用数据库内存。更重要的是，连接池设置过大并不等于 QPS 上限高——如果 SQL 执行慢，再多的连接也只是把等待队列从应用层挪到了数据库层。连接池大小的核心是保证“并发执行中的SQL数量”，超出数据库能并行处理的量，多余连接全是排队。
比较合理的配置思路是：先压测单条核心SQL的耗时，估算数据库能支撑的并发查询数（SHOW ENGINE INNODB STATUS能看到并发线程数），再按这个数字设置连接池的上限。别盲目堆连接数。
在连接池参数上，还有几个高频坑位要排查：
connectionTimeout/maxWait设置太短，比如 HikariCP 的connectionTimeout默认30秒，如果业务 SQL 偶尔有慢查询，连接池请求就会大量超时，引发雪崩；idleTimeout和maxLifetime不匹配，比如maxLifetime默认30分钟，但idleTimeout设成了10分钟，连接刚被创建、空闲不到10分钟就被回收，又马上被新请求建连，造成频繁连接创建；validationTimeout设得太短，导致连接校验经常失败，主动断掉健康连接。
2.2 数据库层：连接数配置、慢查询、锁等待
数据库层的排查顺序，建议是：连接配置 → 慢SQL → 锁状态 → 大事务。
先看配置：
SHOW VARIABLES LIKE 'max_connections'; SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout'; SHOW VARIABLES LIKE 'thread_cache_size';wait_timeout指非交互连接的空闲超时时间，默认8小时。如果应用连接池没有正确回收空闲连接（很多连接池默认不处理空闲，或者空闲超时设得比数据库还长），大量Sleep连接会堆积，直到把max_connections占满。这种堆积的特点非常明显：processlist里全是Sleep状态、time都是几千秒、来源IP集中在应用服务器内网IP。
临时处理方案是把wait_timeout调小：
SET GLOBAL wait_timeout = 300; SET GLOBAL interactive_timeout = 300;这个操作等连接被回收后生效，不需要重启 MySQL，但注意设小了会影响所有客户端，如果应用本身存在合法的长连接业务，要结合场景调整。
慢SQL导致连接爆满的场景更常见。一条执行10秒的慢查询占着连接不放，10条这样的查询就能把连接池的并发通道全部堵死。排查慢SQL最直接的方式是开启慢查询日志：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';定位到慢SQL之后，用EXPLAIN看执行计划。如果 type 是 ALL（全表扫描）、rows 扫描行数巨大、没有走索引，优先考虑加索引；如果走了索引但 rows 还是很大，就要看是不是索引区分度不够或者查询条件本身有问题。
锁等待造成的连接占用也要重点排查。执行：
SELECT * FROM information_schema.innodb_trx; SELECT * FROM information_schema.innodb_locks; SELECT * FROM information_schema.innodb_lock_waits;如果发现长时间未结束的事务，找到源头事务对应的连接，通过KILL <trx_mysql_thread_id>终止它，再观察业务是否恢复。锁等待的典型表现是processlist里多个连接同时处于Locked状态，time还都很大，但 CPU 和慢SQL都不明显。这类问题多源于业务代码里事务边界过大，事务里除了SQL还做了HTTP调用、文件读取等耗时操作，导致锁的持有时间过长。我之前遇到过一段代码在事务里调用外部接口，外部接口超时5秒，事务就挂了5秒，表锁被5秒一度把连接池打爆。修复方式很简单，把外部调用移出事务。
2.3 网络层：连接数被代理/防火墙耗尽
很多人会忽略网络层的问题。MySQL 前面如果挂了代理（比如 ProxySQL、MyCat、MaxScale）、云平台的连接代理，或者应用通过 LVS/HAProxy 转发，那一层也有连接数限制。实例的max_connections没到上限，但代理层的连接池满了，业务同样报连接错误。这类问题有一个特征：直接通过 MySQL 客户端从堡垒机连数据库没问题，但应用连代理就报连接失败。
排查方法分几个方向：
- 查代理机器的连接数——
ss -s看当前 socket 数量，ss -ant | grep 3306 | wc -l看当前到数据库端口的连接数； - 查代理的连接池配置——ProxySQL 的
mysql-connections参数、HAProxy 的maxconn配置； - 查云数据库控制台的“当前连接数”监控——云厂商往往会提供连接数上限，比如 RDS 默认根据规格给几百到几千不等的最大连接数，超过后同样报 too many connections 类错误；
- 查防火墙或安全组规则，有时候安全策略会限制单IP并发连接数，比如单IP最大1000条TCP连接，应用一旦达到就会被丢弃。
网络层面排查的最佳方式其实是“对比法”。把应用服务器上发起的连接数、代理服务器上看到的连接数、MySQLprocesslist里的连接数三个数字放在一起，三者本应一一对应。只要有一个数字明显偏少或者偏多，断点就在那儿。比如 MySQL 侧只有100条，但代理上有1000条连接，差额就是代理上挂死未释放的。
3. 实操复盘：一个完整的爆池处理流程
3.1 第一现场：收集信息而不是盲目重启
有一次排查电商系统的连接池爆满，我拿到手的信息就一句话：“凌晨2点大促预热，订单服务数据库连接池打满，订单接口大面积超时。”
到了服务器上，我先做了四件事：看 MySQL 当前连接数、看活跃线程、看慢查询日志、看应用日志报错。当时得到的数据是：Threads_connected=380，max_connections=400，活跃查询有40多个，其余全是Sleep。慢查询日志里没有特别大的SQL，平均查询耗时都在几十毫秒以内。按这个现场判断，连接数几乎触顶，但查询本身没有大问题，那问题多半出在连接数量的堆积上——活跃查询只有40个，却有340个空闲连接。这就不是慢SQL，而是连接没有被及时回收，或者并发请求瞬间冲高把池子撑满了。
接着查连接来源和会话年龄：
SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host ORDER BY COUNT(*) DESC;结果显示来自订单服务节点A的连接有210条，节点B有90条，其他服务加起来几十条。而我线上订单服务的连接池最大配置只有150。A节点有210条连接，说明A节点的连接池配置被改过，或者有双重连接池叠加。
再往下挖，发现服务里接了两个数据访问组件，一个是 MyBatis 的主连接池，另一个是历史遗留的一个定时任务框架里的独立数据源连接池。两个池子各自配置了150，叠加起来就超过了数据库侧的单机比例。组件没排查过，没人知道它也占连接数。
这次爆池的根因就两条：一是定时任务框架在凌晨跑批，批任务一次性起了大量线程并发申请连接，每个线程池运行时间还很长；二是我方连接池配置未联调，两个连接池叠加后的并发峰值远超 MySQL 允许的400。修复动作分两步走，先把定时任务改为分批次执行，限制最大并发为20；再把两个连接池的maxSize按实际需要重新定义，主连接池120，任务框架连接池30。改完后再看，Threads_connected稳稳停在150以内。
3.2 紧急恢复手段的优先级
遇到正在发生的爆池，恢复业务是第一优先级的。我的建议顺序是：
- 用
SUPER权限账号登录，执行KILL清掉一部分非活跃连接：
-- 杀掉空闲超过300秒的连接（注意先确认再执行） SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE command='Sleep' AND time > 300;把查出来的 KILL 语句复制出来执行。这条操作能迅速腾出连接名额。但不建议直接在命令行一次执行大量动态SQL，容易误杀有权保留的长连接。稳妥做法是查出来确认后再杀。
- 临时调大
max_connections，给应用和排查留出缓冲空间：
SET GLOBAL max_connections = 1000;这里有个注意点，max_connections不是想调多大就调多大。MySQL 为每个连接分配线程和内存（thread_stack、net_buffer_length等），连接数越大内存开销越高。如果机器只有4GB内存，max_connections调到2000，光连接缓冲就可能吃掉2GB。所以调大之前用free -h看一眼内存余量，结合SHOW VARIABLES LIKE 'max_connection_memory%'或者文档给出的单连接内存估算值算一下。
- 如果是慢SQL导致，可以直接定位慢SQL对应的连接ID，
KILL掉对应线程：
SELECT id, time, user, info FROM information_schema.processlist WHERE command='Query' AND time > 10\G大于10秒的查询，如果是大促抢购类活动SQL，可以直接终止顶掉，保证核心链路先通。注意，KILL SELECT 不影响数据一致性，但 KILL UPDATE/INSERT 可能导致事务回滚，要评估影响。
- 如果业务能接受，重启应用释放连接池中的异常连接。但是重启前先确认数据库侧没有大事务，避免重启后应用重新发起请求，把同一个慢SQL再打一遍。重启解决的是“连接还不上”的临时现象，不是根因。
3.3 事后压测验证连接池参数
修复之后，我习惯做一轮连接池压测，验证参数是合理的。压测工具我用的是简单的mysqlslap加应用层 JMeter 组合。先说明一点，压测的目的不是把数据库打爆，而是验证在目标并发下连接数是否会失控。
mysqlslap的用法大概是：
mysqlslap --create-schema=test --query="SELECT * FROM t_order WHERE status=1" -c 200 --iterations=10 --number-of-queries=10000 --concurrency=100这条命令模拟100个并发客户端、执行1万次查询。跑完后看数据库侧的Threads_connected峰值和查询耗时分布。如果峰值稳定在某个值附近，连接池参数就没问题。
更关键的是压测时要盯两个指标：活跃连接数和空闲连接数。用监控脚本定期采样：
while true; do mysql -e "show status like 'Threads_connected'" >> /tmp/conn.log mysql -e "show status like 'Threads_running'" >> /tmp/conn.log sleep 2 done压测期间如果Threads_running长期超过数据库CPU核数，说明SQL执行得不够快，需要从SQL优化端入手，而不是加连接。如果Threads_connected和活跃请求数不匹配，就要从连接泄漏方向去查。
4. 长期治理：监控、参数调优与应急预案
4.1 连接池参数的最优实践参考
衡量连接池配得好不好，不是看峰值有多高，而是看在峰值下请求能否有序排队并及时拿到连接。这里给出一份我实际调优后比较稳妥的参数基准，具体数值要根据业务压测调整：
| 连接池类型 | 参数名 | 建议值 | 说明 |
|---|---|---|---|
| HikariCP | maximumPoolSize | 30~50 | 常规业务建议不要超50，压测后按峰值调整 |
| HikariCP | minimumIdle | 10~20 | 等于最大池时不会回收空闲连接 |
| HikariCP | connectionTimeout | 3000~5000 | 连接申请等待毫秒数，太长容易拖垮调用方 |
| HikariCP | idleTimeout | 600000 | 10分钟空闲回收，必须小于数据库 wait_timeout |
| HikariCP | maxLifetime | 1800000 | 30分钟强制换连接，避免连接被数据库端断开 |
| Druid | maxActive | 50 | 等价于 HikariCP 的 maximumPoolSize |
| Druid | minIdle | 10 | 保留的常驻连接数 |
| Druid | maxWait | 3000 | 获取连接的最大等待毫秒数 |
连接池大小的经验公式，业界有个参考基准：connections = ((core_count * 2) + effective_spindle_count)，其中core_count是数据库服务器CPU核数，effective_spindle_count是磁盘数（SSD 可视为1）。这个公式来自 PostgreSQL 社区的推荐，MySQL 同样适用。它是给高峰期算的连接数参考，而不是最大值。
更贴近业务的估算方式：压测得到单条核心SQL的 P99 耗时，比如 20ms，数据库能支撑的并行 SQL 数量约等于CPU核数 × 50 ÷ P99(ms)，即单核每秒钟大概能执行50条20ms的SQL。8核数据库的理想并发大约是8 * 50 / 20 = 20，所以连接池20~30足够支撑常规流量。当然这只是估算，带宽、锁、磁盘IO都会影响，但至少能帮助避免“拍脑袋设500”这种操作。
4.2 数据库侧参数调优清单
max_connections不是唯一需要看的参数。连接池爆满了，通常还涉及两个隐蔽参数：
第一个是wait_timeout和interactive_timeout。建议线上设置600秒（10分钟），这样连接池里空闲的连接会定期被MySQL断开，促使连接池补建新连接，避免“死连接”堆积。但同时要让应用连接池侧的idleTimeout比这个值小一些，比如300秒，让应用先回收，而不是等MySQL掐断。
第二个是max_execution_time，这个参数可以给 SELECT 语句设置最大执行时间（单位毫秒）。超出时间的查询会被自动终止，避免一条烂SQL把连接占几分钟。只对 SELECT 生效，不影响事务。设置示例：
SET GLOBAL max_execution_time = 3000;对个别慢查询，也可以在语句上加/*+ MAX_EXECUTION_TIME(3000) */提示，作用范围更精确。注意这个参数对存储过程里的 SELECT 不生效，生产环境变更前先在测试环境跑一轮。
第三个容易忽略的是thread_cache_size。连接频繁创建销毁时，MySQL 需要为每个连接创建线程。thread_cache_size控制线程的缓存数量，默认是-1（等于max_connections / 2向上取整），但如果连接数波动很大，建议设成 50~100，让被断开的连接线程能迅速复用，降低建连成本。
4.3 连接数监控和告警配置
连接池爆满这种事，靠人半夜爬起来处理不是长久之计。我的标准做法是三层监控：
第一层，MySQL 侧监控连接数使用率。Prometheus 的mysqld_exporter直接暴露mysql_global_status_threads_connected指标，用 Grafana 做曲线的阈值告警。建议告警阈值设成max_connections * 0.7，70% 就要出动。等到了90%再告警，基本是事故已经在发生了。
第二层，应用侧监控连接池健康度。HikariCP 可以通过micrometer暴露指标，Druid 有自带的监控页面DruidDataSourceStat。关注active、idle、waiting三个指标。waiting长时间大于0，说明连接池排队了。
第三层，慢SQL和锁监控。mysqld_exporter提供mysql_global_status_slow_queries、mysql_global_status_innodb_row_lock_waits，建议做一个独立看板。连接数告警出来时，第一件事看这个看板排查是不是慢SQL引起。
另外，云数据库用户要特别注意控制台上的“连接数使用率”指标和“最大连接数配额”。云实例的 max_connections 往往由规格决定（比如4C8G规格的max_connections是400），买了大规格但临时调大了本地参数，也可能被云侧策略覆盖。我的经验是，用到云 RDS 时先在控制台把最大连接数配额调高，再核对本地参数，否则本地 SET GLOBAL 改了也白改。
4.4 一套可以直接落地的应急预案脚本
这套脚本我按生产环境整理了一套，遇到告警直接执行，不需要现场敲命令。核心逻辑：统计空闲连接 → 按阈值杀掉 → 记录现场。
#!/bin/bash # 连接池爆满急救脚本 MYSQL_USER="root" MYSQL_PASS="yourPassword" MYSQL_HOST="127.0.0.1" KILL_THRESHOLD=300 # 空闲超过300秒的连接 # 第1步：记录现场 mysql -h$MYSQL_HOST -u$MYSQL_USER -p$MYSQL_PASS -e "SELECT NOW() AS time, COUNT(*) AS total_conn FROM information_schema.processlist\G" >> /tmp/conn_crash_$(date +%F_%H%M%S).log mysql -h$MYSQL_HOST -u$MYSQL_USER -p$MYSQL_PASS -e "SHOW STATUS LIKE 'Threads_connected';" >> /tmp/conn_crash_$(date +%F_%H%M%S).log # 第2步：生成杀空闲连接SQL mysql -h$MYSQL_HOST -u$MYSQL_USER -p$MYSQL_PASS -N -e "SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE command='Sleep' AND time > $KILL_THRESHOLD AND user != 'event_scheduler';" > /tmp/kill_sleep.sql # 第3步：提示确认后执行 echo "Generated kill script: /tmp/kill_sleep.sql. Review then execute: mysql -h$MYSQL_HOST -u$MYSQL_USER -p$MYSQL_PASS < /tmp/kill_sleep.sql"脚本里我故意把杀掉空闲连接拆成两步，先输出SQL文件，人工确认后再执行。因为有些合法的空闲连接（比如长连接存活的报表服务）不应该被杀，一刀切容易误伤。生产环境要谨慎，自动化的前提是确认过连接来源。
5. 排查小结与速查表
5.1 报错现象对应根因判断逻辑
把遇到的爆池现象和根因对应起来，形成一张速查表能省很多时间：
| 现象 | 优先怀疑方向 | 核心排查命令/指标 |
|---|---|---|
Too many connections+Sleep堆积 | 应用连接未释放 / 空闲超时太长 | processlist按time排序；确认wait_timeout |
Too many connections+ 大量Query且 time 大 | 慢SQL / 无索引 | 慢查询日志、EXPLAIN；检查long_query_time |
Too many connections+Locked状态 | 锁等待 / 大事务 | innodb_trx、innodb_lock_waits视图 |
| 连接池超时 + MySQL侧连接数正常 | 应用连接池配置过小 / 连接泄漏 | 活跃连接曲线、线程堆栈、代码评审 |
| 应用连不上 + 命令行能连 | 代理/防火墙连接耗尽 | 代理连接监控、ss -ant、安全组规则 |
| 高峰期爆 + 平日正常 | 容量规划不足 / 突发流量 | 压测峰值、Threads_connected历史曲线 |
| 连接数量正常但接口依然慢 | CPU/IO瓶颈 | SHOW PROCESSLIST、top、iostat |
5.2 需要沉淀复盘的关键输出
每次处理完连接池爆满问题，建议把三样东西沉淀下来，后续同类问题能做到开箱即用。
第一是故障时间线，精确到分钟，记录报警触发、开始排查、执行干预、业务恢复、参数变更完成这几个时间点，方便大促前复盘。
第二是连接数峰值记录，把Threads_connected的峰值、max_connections的实时值、活跃查询数、慢SQL数量都保留下来。这些数据是后续调参数的依据。没有数据支撑，谁也不敢说“调到100够了”还是“要调到200”。
第三是变更记录。谁在什么时间改了连接池参数、改了数据库配置、上线了新代码，这些都要记录。很多连接池爆满其实就是配置变更引起的——某次上线把连接池maximumPoolSize从50改成了500，某次DBA把max_connections调小了，这类变更在故障复盘里是最常见的元凶。
我个人处理这类问题最深的一点体会是：连接池爆满了不要第一反应去“加连接”，而是先问“这些连接为什么还不释放”。多数情况下连接数不是不够，是流转不动。慢SQL、锁等待、空闲连接不回收才是核心症结。盲目把max_connections从400调到4000，只会让数据库在故障时承担更多无效连接，最终拖垮整个实例。正确的方向永远是让连接“快借快还”，其次才是加容量。
最后分享一个小技巧：如果你用的是 HikariCP，可以直接把poolName配置加上，比如poolName: OrderServicePool。这样连接丢失时，日志里能看到“OrderServicePool - Connection is not available...”而不是光秃秃的HikariPool-1。这个看起来不起眼的配置，在排查多服务、多数据源的时候能帮你省下大量核对的时间。线上排查遇到连接池爆满，日志里能直接定位到是哪个服务、哪个连接池出了问题，剩下的就是按流程走了。
