MySQL 连接数爆满 Too many connections？3 步定位真凶（附实战复盘）
摘要： 凌晨告警群里弹出 Too many connections，业务全白屏。重启 MySQL、调大 max_connections 都只是缓兵之计。本文用 3 条命令 + 2 个隐藏真凶，把连接数打满从「现象」讲到「根因」，并附一段真实踩坑复盘。新手照着敲就能用。
一、先别急着调大参数
看到 Too many connections 这一行，多数人的本能反应是：调大 max_connections，或者重启 MySQL 释放连接。看着恢复了，以为稳了------结果下午同一时间又满。
说白了，连接数打满是「果」，根因在别处。调大参数只是掩耳盗铃：
- 连接泄漏还在，调大只是拖时间；
- 业务反复雪崩，客户开始投诉；
- 时间线拼不出，复盘全靠猜；
- 防汛防台巡检期，机房怕这种悄悄满的慢病。
连接数打满从来不是数据库的问题，是「谁在占着连接」的问题。
二、3 条命令揪出连接真凶
① SHOW PROCESSLIST：看清谁占着
先看哪些连接卡着、在干嘛、卡了多久。重点盯两类：Command=Sleep 且 Time 很大的，以及 State 卡在 sending data / Locked 的。
SHOW PROCESSLIST;
-- 关注 Time 列：Sleep 几小时不掉，基本就是连接泄漏② Threads 状态：判断是否异常增长
用 SHOW GLOBAL STATUS 看连接相关计数，再对着 max_connections 看水位。
SHOW GLOBAL STATUS LIKE 'Threads_%';
SHOW VARIABLES LIKE 'max_connections';
-- Threads_connected 接近 max_connections，就快爆了
-- Threads_created 一直在涨，说明连接频繁新建销毁③ wait_timeout + KILL：让闲置连接自动回收
调小 wait_timeout，让长时间闲置的连接自动断开；应急时直接 KILL 掉明显卡死的连接。
SHOW VARIABLES LIKE 'wait_timeout';
SET GLOBAL wait_timeout = 300; -- 闲置 5 分钟自动断开
KILL 12345; -- 应急杀掉卡死连接（填 processlist 里的 Id）这三条我贴在工位上很久了，新人照着敲，十几分钟能定位。重启是掩耳盗铃，这三条才是把脉。
三、调大却更卡？2 个隐藏真凶
光调大 max_connections 救不了的情况，基本是下面两个：
真凶① 连接泄漏
- 应用拿了连接不归还；
- 连接池
maxIdle设得不合理； processlist里一堆Sleep几小时不掉；- 调大参数只是把爆的时点往后拖。
真凶② 慢查询拖死
- 一条没索引的查询扫全表；
- 连接长期占着不释放，连接数被慢查询堆满；
- 这时加连接数只会让更多慢查询同时跑，更卡。
这两种，调大
max_connections都救不了，得从应用层（关连接）和索引层（治慢查询）下手。
四、真实复盘：上个月我踩的坑
上个月我自己就踩了一次。告警来了，我把 max_connections 从 200 调到 800，监控看着正常，关机睡觉，以为稳了。结果第二天同一时间告警又来。
后来一查，真因是某业务代码异常，连接拿了没关。我调的是数据库参数，泄漏却在应用层。重启那个出问题的服务，连接才真回来。
当时我反复确认了好几遍，差点以为中邪了。这事儿给我一个提醒：半夜这种告警，光靠脑子记容易漏，得有个地方把谁接了、查到哪步记下来。
五、防复发：把故障变成可复盘
- **可复盘档案：**这次根因是什么、谁处理的、花了多久，记下来，下回同类问题十分钟能灭。故障变经验，不是变事故。
- **让系统反脆弱：**每次处置沉淀成预案，下次同类告警直接照着走。这就是把基础设施「反脆弱」化------热词嵌入：反脆弱。
- **工具替你记：**想偷懒，找个接企业微信、告警能自动建单的系统，比如宝企通，省得半夜靠脑子记。当然，也有人不这么想，觉得小团队人盯人就够；我理解，人少能扛，但业务一多，防汛防台那种节点靠人盯就是赌运气。
做了几年运维，我越来越觉得，含金量不在你会多少命令，在于每一次故障能不能变成下次能复盘的档案。工具是工具，能把故障变成可复盘的，终究是人。
结尾
如果你正好在搜 中小企业工单系统哪家好用 ，关注我，后面再聊 SaaS工单系统哪家性价比高，不急着买，先把思路理顺。你被连接数爆满坑过几次？评论区说下你的场景，我挑几条回具体怎么改。
#MySQL#运维#Too many connections#故障排查#数据库连接池