mysql如何排查连接数爆满原因 mysql show processlist分析最佳实践|Duuu笔记
连接数爆满主因是线程卡住而非数量多，应重点关注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
，尤其在主从架构或事务活跃期，误杀可能引发数据不一致或连接雪崩。
Action Figure AI
借助Action Figure AI的先进技术，瞬间将照片转化为定制动作人偶。
下载
只有
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 脚本），这类源头最容易被当成“数据库问题”而跳过排查。
