网络抖动导致的僵尸事务不会自动释放，因线程卡在updating、locked等非空闲状态，wait_timeout不生效；需查innodb_trx中trx_state='running'且trx_query is null、trx_started超300秒的记录，再关联processlist确认info为空、state异常、process_time小但trx_started很老，最后通过performance_schema.threads排除background线程后kill trx_mysql_thread_id。
网络抖动导致的僵尸事务不会自动释放，wait_timeout 对它完全无效——因为线程卡在 Updating、Locked 或 Writing to net 状态，根本不算“空闲”，所以超时机制压根不触发。
查 INNODB_TRX 找运行时间异常长的 RUNNING 事务
真正卡住的僵尸事务，往往表现为 TRX_STATE = 'RUNNING' 却没有实际 SQL 在执行（TRX_QUERY IS NULL），且 TRX_STARTED 时间远超业务正常耗时。这不是慢查询，是失联残留。
- 用这个语句快速筛出可疑项：
SELECT TRX_ID, TRX_MYSQL_THREAD_ID AS thread_id, TRX_STATE, TRX_STARTED, TRX_QUERY, TIMEDIFF(NOW(), TRX_STARTED) AS duration FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND (TRX_QUERY IS NULL OR TRX_QUERY = '') AND TIME_TO_SEC(NOW() - TRX_STARTED) > 300;
-
TRX_STARTED是事务开始时间，不是连接创建时间；超过 5 分钟还RUNNING且无TRX_QUERY，基本可判为僵尸 - 注意：
TRX_MYSQL_THREAD_ID是后续KILL的目标 ID，不是TRX_ID
关联 PROCESSLIST 确认连接是否已失效
一个事务还在 INNODB_TRX 里挂着，不代表对应连接还活着。客户端 crash 或网络中断后，MySQL 线程可能停留在非 Sleep 状态但早已收不到指令。
- 执行关联查询：
SELECT t.TRX_ID, p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME AS process_time, p.STATE, p.INFO FROM INFORMATION_SCHEMA.INNODB_TRX t LEFT JOIN INFORMATION_SCHEMA.PROCESSLIST p ON t.TRX_MYSQL_THREAD_ID = p.ID WHERE t.TRX_STATE = 'RUNNING' AND (t.TRX_QUERY IS NULL OR t.TRX_QUERY = '') AND TIME_TO_SEC(NOW() - t.TRX_STARTED) > 300;
- 重点看三列：
INFO IS NULL、STATE是Locked/Waiting for table metadata lock/Writing to net、process_time很小（比如 1–5 秒）但TRX_STARTED很老 - 如果
COMMAND = 'Sleep'且process_time > 300，那更可能是空闲连接未清理，和僵尸事务无关
别直接 KILL，先排除后台线程和 DDL
误杀备份线程或正在执行 ALTER TABLE 的线程，可能引发严重后果。MySQL 不会阻止你 KILL，但它也不会告诉你这个线程是不是关键后台任务。
- 查
performance_schema.threads确认线程类型：SELECT THREAD_ID, NAME, TYPE, PROCESSLIST_ID, PROCESSLIST_COMMAND, PROCESSLIST_STATE FROM performance_schema.threads WHERE PROCESSLIST_ID = ?;
- 跳过
TYPE = 'BACKGROUND'的线程（如thread/sql/event_scheduler） - 跳过
PROCESSLIST_COMMAND IN ('Query', 'Execute') AND PROCESSLIST_STATE LIKE '%alter%'的线程 - 批量清理时加
LIMIT 3控制节奏，避免瞬间触发大量 undo 回滚拖垮 I/O
最易被忽略的一点：KILL 后事务不会秒退。如果事务涉及大更新或磁盘压力高，回滚可能持续数分钟，此时 INNODB_TRX 里仍可见该记录，状态变成 ROLLING BACK——这不是失败，是正在努力清理。重复 KILL 不仅无用，还会加剧系统负载。
