wait_timeout对僵尸事务完全无效，因其仅清理Sleep状态的空闲连接，而网络抖动导致的僵尸事务线程处于Updating/Locked等活跃状态，不触发超时机制；需通过INNODB_TRX与PROCESSLIST主动识别并KILL。
wait_timeout 对网络抖动导致的僵尸事务完全无效——它只杀空闲连接，不碰正在卡住的事务。
为什么 wait_timeout 无法清理僵尸事务
网络抖动中断客户端后，MySQL 线程往往卡在 Updating、Locked 或 Writing to net 状态，而非 Sleep。而 wait_timeout 的触发前提是连接处于空闲（即无任何活跃语句、未持锁、未等待响应）状态。只要事务里有一条 SELECT FOR UPDATE 或大字段 INSERT 卡在网络传输阶段，线程就一直算“活跃”，wait_timeout 根本不会计时。
此时查 SHOW PROCESSLIST，你会看到 State 不是 Sleep，Time 字段可能很小（比如 2 秒），但事务实际已失联数分钟。
怎么快速识别真正卡住的僵尸事务
别等超时，得主动扫描。核心依据是：事务开始时间远早于当前时间，且客户端已无响应。
- 用
INNODB_TRX找运行超 5 分钟的事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 300 - 关联
PROCESSLIST查对应线程：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = ? - 重点看三项：
INFO IS NULL（客户端没发新语句）、STATE是Waiting for table metadata lock或Locked、TIME值异常小但trx_started很老 - 别直接
KILL—— 先确认不是备份线程：SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?，排除THREAD_TYPE = 'BACKGROUND'或正在执行ALTER TABLE
如何避免下次再被卡住
关键不是调大 wait_timeout，而是让事务本身更短、连接更可控：
- 应用层拆长事务：把耗时操作拆成多个小事务，每步处理完立刻
COMMIT，避免单个事务横跨多次网络往返 - 连接池必须开探活：
HikariCP配connection-test-query=SELECT 1+validation-timeout=3000+idle-timeout=600000（比 MySQL 的wait_timeout小至少 60 秒） - 客户端设 socket 级超时：
pymysql连接加connect_timeout=10、read_timeout=30；JDBC URL 加socketTimeout=30000 - 禁用
autoReconnect=true：MySQL 5.5+ 已废弃，它不会静默续连，只会掩盖事务断裂风险，且丢失锁、变量、预编译语句
如果真要调 wait_timeout，必须同步改这些
单独改 wait_timeout 是徒劳的。它只管空闲期，而僵尸事务根本不空闲。但若你仍需延长空闲连接寿命（比如调试场景），必须：
- 同时改
wait_timeout和interactive_timeout，值设一致，否则 JDBC 客户端可能因驱动行为差异走错路径 - 改配置文件（
/etc/my.cnf的[mysqld]段落），不是只跑SET GLOBAL—— 后者重启即失效 - 重启 MySQL 进程（
systemctl restart mysql），reload不生效 - 云数据库（如 RDS）通常不支持
SET GLOBAL，得走控制台参数模板或提工单，且最小值常被限制为 60 秒
最易被忽略的一点：即使你把 wait_timeout 设成 300 秒，若连接池的 max-lifetime 是 1800 秒，那连接大概率在被池回收前就被 MySQL 先断了——参数必须成对对齐，且以连接池的探活机制为第一道防线。
