连接数爆满主因是线程卡住而非数量多，应重点关注SHOW FULL PROCESSLIST中State非Sleep且Time＞60秒的阻塞线程，优先排查应用端连接未释放、监控脚本高频查询及本地进程异常连接。
直接看 SHOW PROCESSLIST 里哪些线程在“卡住”
连接数爆满，往往不是连接多，而是大量线程卡在某个状态迟迟不释放。SHOW PROCESSLIST 的 State 和 Time 列才是关键线索，而不是只盯着总连接数。
-
State是“等待锁”还是“写磁盘中”？比如Waiting for table metadata lock、Writing to net、Creating sort index都意味着线程被阻塞或资源吃紧 -
Time超过 60 秒的非Sleep线程必须优先关注；超过 300 秒的基本可以判定为异常挂起 - 别只用
SHOW PROCESSLIST—— 它默认只返回前 100 条，要用SHOW FULL PROCESSLIST才能看到完整 SQL，否则可能漏掉长查询的真正内容
过滤出真问题：用 information_schema.processlist 做条件查杀
手动翻页看 processlist 效率低还容易误判，直接查表 + 拼接 kill 更可靠，但要注意表来源和字符集陷阱。
- 推荐用
SELECT * FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME > 60 ORDER BY TIME DESC，避免查到大量空闲连接干扰判断 - 千万别在高并发时频繁查
information_schema.processlist—— 它是临时表，8.0+ 版本会全局加锁扫描线程列表，本身就会拖慢整个 MySQL（已有线上案例证实它引发 insert 延迟） -
performance_schema.processlist更轻量（内存表），但需确认已开启：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'，值为ON才可用
KILL 前先确认权限和影响范围
不是所有线程都能随便 KILL，尤其在主从架构或事务活跃期，误杀可能引发数据不一致或连接雪崩。
- 只有
SUPER或CONNECTION_ADMIN权限用户才能KILL其他用户的线程；普通应用账号只能KILL自己的 - 正在执行
INSERT/UPDATE/DELETE的线程被KILL后，事务会回滚，但若已写 binlog，从库可能重放失败（半同步下更敏感） - 别用脚本一键清空所有非 Sleep 连接 —— 比如
Binlog Dump线程是主从复制必需的，KILL它会导致从库 IO 线程断连
连接数持续上涨？重点查应用端和中间件
MySQL 层面看到连接爆满，90% 的根因不在数据库本身，而在上层连接没释放或配置失当。
- 检查应用是否用了连接池但未设置
maxLifetime或idleTimeout，导致大量 stale 连接堆积（如 HikariCP 默认不主动清理空闲连接） - 确认监控脚本是否高频轮询
SHOW PROCESSLIST—— 已有明确案例：两分钟一次的监控脚本反复查information_schema.processlist，直接导致 insert 延迟翻倍 - 注意客户端异常断连后，MySQL 不会立刻回收连接，要依赖
wait_timeout（默认 28800 秒）或interactive_timeout触发清理，这个时间窗口内连接仍计入总数
最常被忽略的一点：SHOW PROCESSLIST 看到的 Host 列如果是 127.0.0.1:xxxx 或 localhost:xxxx，说明连接来自本地进程（比如定时任务、监控 agent、甚至 crontab 脚本），这类源头最容易被当成“数据库问题”而跳过排查。
