僵死会话指客户端断开后连接未释放或事务卡住未提交/回滚的会话，表现为SHOW PROCESSLIST中Command为Sleep且Time>300秒，或State为Locked/Waiting for table metadata lock等长时间无响应状态。
MySQL里哪些会话算“僵死”，怎么快速识别
僵死会话不是指MySQL进程挂了，而是客户端断开后连接没释放、或者事务卡住没提交/回滚，导致连接持续占用线程和内存。这类会话在 SHOW PROCESSLIST 里通常表现为 Command 列是 Sleep 但 Time 超过 300 秒，或者状态是 Locked / Waiting for table metadata lock 却长时间不动。
实操建议：
- 用
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE TIME > 300 AND COMMAND != 'Sleep';筛出可疑长时会话 - 重点看
STATE是Waiting for table metadata lock的——这往往是 DDL 操作被阻塞，背后可能有未提交的事务锁着表 - 别只看
TIME，有些监控脚本误杀刚建立的连接，要结合INFO（是否为空）和业务时间点交叉判断
KILL语句能直接干掉所有僵死连接吗
不能。MySQL 的 KILL 分两种：KILL CONNECTION（或简写 KILL）终止连接；KILL QUERY 只中断当前正在执行的语句，保留连接。对僵死会话，多数情况该用 KILL CONNECTION，但得注意权限和副作用。
实操建议：
- 执行前确认你有
PROCESS和SUPER权限（5.7+ 还需CONNECTION_ADMIN） - 避免用
KILL 123这种裸ID，先查清楚ID对应的是谁：SELECT ID, USER, HOST, DB, INFO FROM information_schema.PROCESSLIST WHERE ID = 123; -
KILL CONNECTION会立即关闭 TCP 连接，但若对方正在写 binlog 或刷脏页，可能触发一次小范围刷盘，高并发下慎批量执行 - 不要对
system user或event_scheduler执行KILL，会导致 MySQL 内部功能异常
自动清理僵死会话，靠 wait_timeout 还是 interactive_timeout
这两个参数控制空闲连接超时，但它们只对 Command = Sleep 的连接生效，且不处理卡在锁等待、大事务回滚中的“伪僵死”会话。默认值（28800秒=8小时）在生产环境几乎等于不生效。
实操建议：
- 调整前先确认应用是否用了连接池——很多连接池自己管理空闲时间，盲目调小
wait_timeout会导致连接池频繁重建连接，反而增加开销 - 如果确定用不到长连接，可设为
300（5分钟），但必须同步检查应用层是否有未关闭的ResultSet或Statement，否则会报MySQLNonTransientConnectionException: No operations allowed after connection closed -
interactive_timeout影响的是带CLIENT_INTERACTIVE标志的连接（比如 mysql 命令行），一般不用动它 - 真正可靠的自动清理得靠外部巡检脚本，每5分钟跑一次
KILL CONNECTION+ 条件过滤，比依赖超时参数更可控
权限受限时，普通用户如何安全释放自己的僵死连接
普通用户没有 SUPER 权限，无法 KILL 别人的会话，但可以 KILL 自己的——前提是知道自己的连接 ID。不过，很多人连自己当前连接 ID 都不知道，更别说手动 KILL。
实操建议：
- 登录后立刻执行
SELECT CONNECTION_ID();记下 ID，后续出问题时可用KILL CONNECTION @conn_id;（注意不是KILL @conn_id） - 在应用代码里，连接初始化后存一下
connection_id()，出错日志里打出来，方便事后定位 - 如果应用用的是 ORM（如 MyBatis、Hibernate），注意某些配置（如
autoReconnect=true）会让连接在异常后静默重连，旧连接可能残留，此时KILL旧 ID 反而影响新连接逻辑 - 最稳妥的方式：让应用层实现连接健康检查 + 主动 close，而不是等 DB 层兜底
真正难处理的不是 sleep 几小时的连接，而是那种 State = Sending data 却卡住 20 分钟的查询——它可能正在扫描亿级表，KILL 它会触发完整回滚，耗时可能比执行还长。这种得先看执行计划、加索引，而不是急着 kill。
