先看Threads_connected与Threads_running是否严重失衡，再查SHOW PROCESSLIST中Time值高的Sleep或Locked连接；若Threads_connected≥90%max_connections且Threads_running远小于此（如480 vs 12），说明连接空转或卡住，非真实并发上涨。
连接数瞬间暴涨不是并发突增，而是连接没释放或被卡住——先看 Threads_connected 和 Threads_running 的差值，再查 SHOW PROCESSLIST 里 Time 值高的 Sleep 或 Locked 连接。
怎么看是不是真爆了：别信报错，信三组数值
报 Too many connections 不代表一定是连接数打满，也可能是网络、权限或进程僵死。真正要盯的只有三个值：
-
SHOW VARIABLES LIKE 'max_connections';—— 看上限（默认常为 151 或 500） -
SHOW STATUS LIKE 'Threads_connected';—— 当前所有已建立连接数（含 Sleep） -
SHOW STATUS LIKE 'Threads_running';—— 正在执行 SQL 的活跃线程数
如果 Threads_connected ≥ 90% max_connections，且 Threads_running 远小于前者（比如 480 vs 12），基本可断定是大量连接空转或卡住，不是真实业务并发上来了。
为什么 Sleep 连接 Time 值几百秒还活着
MySQL 默认 wait_timeout 是 28800 秒（8 小时），但应用层连接池早该回收了。出现几百秒的 Sleep，说明连接泄漏或配置失配：
- HikariCP 的
idleTimeout必须小于 MySQL 的wait_timeout，否则连接池以为连接还活，MySQL 却已准备断开 - Druid 的
removeAbandonedOnBorrow若关闭，泄漏连接不会被强制回收 - Django ORM 默认长连接，若
CONN_MAX_AGE设为0或过大，也会堆积 - 代码里
try里开了连接，catch或finally没close()，尤其在异常分支里
怎么快速定位谁在拖后腿：用 SHOW FULL PROCESSLIST 看四列
执行 SHOW FULL PROCESSLIST; 后，重点扫视以下四列组合：
-
User+Host：哪个应用用户、从哪台机器连进来？突然冒出陌生 IP 或测试账号，就是源头 -
Command：大量Sleep是空闲未关；Query且State是Locked或Sending data，大概率是锁等待或慢查询 -
Time：单位秒。超过 300 秒的Sleep基本可杀；超过 60 秒的Query要结合慢日志看 -
State：如updating、Copying to tmp table、Waiting for table metadata lock，直接暴露阻塞点
特别注意那些 Time 高、State 是 Locked 且 User 来自同一服务实例的连接——这往往是一条没索引的 UPDATE 锁住了整张表，后面几十个请求全在排队等锁，每个都占一个连接。
临时止血但不能依赖的操作
紧急恢复可用性可以做，但只是给排查留出时间，不是解决方案：
- 手动
KILL掉Time > 300且非system user的Sleep连接（避开复制线程和监控账号） -
SET GLOBAL wait_timeout = 300;—— 让空闲连接更快释放（需SYSTEM_VARIABLES_ADMIN权限） -
SET GLOBAL max_connections = 600;—— 仅限重启前应急，每个连接吃内存（约 256KB～1MB），设太高可能触发 OOM
真正要盯住的是三个协同点：应用连接池最大数 × 实例数，不能超 max_connections 的 70%；wait_timeout 必须比连接池 idleTimeout 大，但差值不宜超 60 秒；业务代码里所有数据库操作，必须确保在 finally 或 try-with-resources 中显式释放连接——哪怕只有一处漏掉，故障就会反复。
