数据库连接池爆了，这3个命令能救你一次

“应用突然连不上数据库了”——这是运维最怕听到的报警之一。紧接着监控图上数据库连接数直线飙升直到打满上限新的连接请求全部被拒绝。业务瞬间中断用户端开始报错。这就是经典的数据库连接池耗尽故障。不管你是Java的HikariCP、Tomcat JDBC还是Go、PHP的连接池一旦并发请求超过连接池上限或者连接未正确释放就会触发这场“雪崩”。别慌。下面这三个命令能在第一时间帮你把业务抢救回来。第1个命令看看当前到底有多少连接SHOW PROCESSLIST;或者更直观地统计连接状态SELECT command, COUNT(*) FROM information_schema.processlist GROUP BY command;作用快速了解当前连接都在干什么。Command列显示Sleep表示空闲连接Query表示正在执行的SQLLockedMySQL 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的团队来说把数据库的日常巡检和应急兜底交给这样的专业服务也是一种务实的选择。