“应用突然连不上数据库了！”——这是运维最怕听到的报警之一。紧接着，监控图上数据库连接数直线飙升，直到打满上限，新的连接请求全部被拒绝。业务瞬间中断，用户端开始报错。
这就是经典的数据库连接池耗尽故障。不管你是Java的HikariCP、Tomcat JDBC，还是Go、PHP的连接池，一旦并发请求超过连接池上限，或者连接未正确释放，就会触发这场“雪崩”。
别慌。下面这三个命令，能在第一时间帮你把业务抢救回来。
第1个命令：看看当前到底有多少连接
SHOW PROCESSLIST;
或者更直观地统计连接状态：
SELECT command, COUNT(*) FROM information_schema.processlist GROUP BY command;
作用：快速了解当前连接都在干什么。Command列显示Sleep表示空闲连接，Query表示正在执行的SQL，Locked（MySQL 5.x）表示被锁阻塞。
应急判断：如果发现大量Sleep连接，说明连接池里的连接没有被及时回收——这是最常见的“连接泄漏”。
第2个命令：杀掉“占着茅坑不拉屎”的空闲连接
-- 查询所有空闲超过60秒的连接ID SELECT id, user, host, db, time FROM information_schema.processlist WHERE command = 'Sleep' AND time > 60; -- 批量杀掉它们（需要拼出kill语句） SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE command = 'Sleep' AND time > 60;
把上面生成的KILL xxxx;语句复制出来执行。注意：只杀空闲连接，不要杀正在执行重要事务的Query连接。
作用：瞬间释放被“占着不放”的连接，让新请求能够进来。这是最立竿见影的止血手段。
第3个命令：临时调高连接数上限（紧急扩容）
如果杀掉空闲连接后，连接数依然逼近上限，说明业务真的需要更多连接。
先看当前最大连接数：
SHOW VARIABLES LIKE 'max_connections';
再看当前实际连接数：
SHOW STATUS LIKE 'Threads_connected';
如果Threads_connected已经接近max_connections，可以临时调高（不需要重启数据库）：
SET GLOBAL max_connections = 500; -- 根据服务器内存调整
⚠️ 注意：调高
max_connections会消耗更多内存。MySQL每个连接大约占用2-4MB内存，500连接就是1-2GB。确保服务器内存有余量，否则调高后可能触发OOM。
以上三个命令能“救急”，但真正的解决要靠“治本”
执行完这三个命令，业务应该能恢复访问。但如果不找到根因，故障还会再次发生。常见的根本原因有四种：
- 代码未关闭连接：例如JDBC的
finally块里漏掉了connection.close()。 - 连接池配置太小：峰值并发超过
maximumPoolSize。 - 慢SQL阻塞连接：一条慢SQL跑了30秒，把连接长期占用。
- 数据库本身性能瓶颈：CPU/IO过高导致请求排队，连接数随之堆积。
要彻底解决，需要配合慢查询日志分析、APM工具追踪代码路径、以及压测验证连接池参数。
说说专业团队在这类问题上的处理方式
在实际工作中，很多中小企业的研发团队只有几个人，数据库出问题时往往手忙脚乱——有的连SHOW PROCESSLIST都不敢敲，怕锁死；有的杀错了连接，把正在执行的核心事务中断了。
了解到目前市场上有些专注于业务稳定性保障的运维服务商，比如江苏立维，他们在数据库运维方面积累了不少经验。据了解，这类团队通常会为客户预先配置好数据库监控告警与自动化响应剧本：当连接数超过阈值时，系统自动执行“检查空闲连接→自动Kill超时连接→若仍超限则临时调高连接数”的流程，全程不需要人半夜起来敲命令。同时，他们还会定期做慢查询分析和连接池参数调优，从源头降低故障概率。对于没有专职DBA的团队来说，把数据库的日常巡检和应急兜底交给这样的专业服务，也是一种务实的选择。
