应查information_schema.innodb_trx而非show processlist，因后者将持锁空闲事务显示为sleep/null，无法反映真实状态；innodb_trx通过trx_state='running'且trx_query is null可精准识别未提交卡住的事务。
查 INNODB_TRX 而不是 SHOW PROCESSLIST
空闲事务在 SHOW PROCESSLIST 里几乎都显示为 Command = 'Sleep'、Info = NULL、State = ''，看起来人畜无害，但实际可能已持锁 5 分钟。真正能暴露它“空转中”本质的是 information_schema.INNODB_TRX 表：TRX_STATE = 'RUNNING' 且 TRX_QUERY IS NULL，说明事务没提交也没执行新语句，纯卡住。
推荐用这个查询快速筛出风险项：
SELECT TRX_ID, TRX_MYSQL_THREAD_ID AS thread_id,
TIMESTAMPDIFF(SECOND, TRX_STARTED, NOW()) AS sec,
TRX_STATE, TRX_QUERY, TRX_ISOLATION_LEVEL
FROM information_schema.INNODB_TRX
WHERE TRX_STATE = 'RUNNING'
AND TRX_QUERY IS NULL
AND TIMESTAMPDIFF(SECOND, TRX_STARTED, NOW()) > 60;
注意：TRX_STARTED 是事务真实起始时间，比 PROCESSLIST.TIME 可靠得多；别信 TIME > 300 就杀——有些连接刚建好还没发 SQL，TIME 就开始计了。
确认是否真可杀：看用户、主机和命令类型
拿到 TRX_MYSQL_THREAD_ID 后，不能直接 KILL。先关联 information_schema.PROCESSLIST 查上下文：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = <thread_id>;</thread_id>
- 如果
USER是应用账号（如app_user）、HOST是业务服务器 IP、COMMAND是Sleep、INFO为空、TIME远大于事务持续秒数 → 基本可判定为“应用忘记 commit/rollback 后断连残留” - 如果
USER是root或监控工具（如DBeaver、Navicat），且STATE是Waiting for table metadata lock→ 很可能是人工操作中途退出，需优先处理 - 排除
system user、event_scheduler、monitor类连接，误杀会导致 MySQL 内部异常
用 KILL CONNECTION，不是 KILL QUERY
空闲事务没有正在执行的语句，KILL QUERY 对它完全无效，只会返回 “Query killed” 却不释放事务。必须用 KILL CONNECTION <thread_id></thread_id>（MySQL 5.7+ 等价于 KILL <thread_id></thread_id>）来切断连接，触发隐式回滚。
执行后立刻验证效果：
- 查
INNODB_TRX：该TRX_ID应消失，或状态变为ROLLING BACK - 不要只看
PROCESSLIST里有没有那个ID——线程 ID 可能被复用，残留的ROLLING BACK事务仍会阻塞 DDL - 若
TRX_STATE长时间卡在ROLLING BACK，说明回滚量大，需观察SHOW ENGINE INNODB STATUS中的进度提示
生产环境加过滤条件降低误杀风险
盲目扫全表 INNODB_TRX 容易命中运维脚本或报表任务。建议加安全围栏：
- 限定隔离级别：
TRX_ISOLATION_LEVEL = 'REPEATABLE-READ'（绝大多数业务事务默认值，READ-COMMITTED事务通常不长期持锁） - 排除高权限用户：
TRX_MYSQL_THREAD_ID NOT IN (SELECT ID FROM information_schema.PROCESSLIST WHERE USER = 'root') - 结合主机白名单：
HOST LIKE '10.20.%'或排除跳板机 IP
最易被忽略的一点：kill 后必须盯住 INNODB_TRX 是否清空，而不是等 PROCESSLIST 消失——因为回滚未完成时，事务资源仍在，后续 ALTER TABLE 或 TRUNCATE 依然会被卡住。
