失控长事务的关键识别标志是：在INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE='RUNNING'、TRX_ROWS_MODIFIED=0且TRX_STARTED远早于当前（如超30分钟），表明其仅执行只读操作却长期未提交，持续占用undo log和内存资源，而非普通慢查询。
如何识别正在失控的长事务（而非普通慢查询）
关键区别在于：失控长事务通常不持有行锁、不阻塞其他写入，但持续占用 undo log 和内存资源，导致 information_schema.INNODB_TRX 中 TRX_STATE = 'RUNNING' 且 TRX_ROWS_MODIFIED = 0，同时 TRX_STARTED 时间远早于当前（比如超过 30 分钟）。这类事务常见于误执行的未提交 BEGIN + 大量 SELECT 或中间断开的应用连接。
不要只看 SHOW PROCESSLIST 的 Time 列——它反映的是线程空闲时长，不是事务活跃时长。必须查 INNODB_TRX：
SELECT trx_id, trx_mysql_thread_id, trx_started, trx_state, trx_rows_modified FROM information_schema.INNODB_TRX WHERE UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(trx_started) > 1800;
若返回结果中 trx_rows_modified 恒为 0，基本可判定是“挂起型”失控事务。
为什么不能直接 KILL thread_id 就完事
KILL 命令只是向线程发送中断信号，MySQL 需要等待事务当前操作自然结束才能响应。对一个正在扫描千万级表的 SELECT，KILL 后可能卡住数分钟，期间仍占用 buffer pool、undo slot，甚至拖慢整个实例的 purge 线程。
更危险的是：如果该事务原本在执行 INSERT ... SELECT 或大事务 UPDATE，KILL 触发回滚时会引发大量磁盘 IO 和 CPU 消耗，影响线上查询延迟。
所以必须分两步走：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 先确认它没在修改数据（
TRX_ROWS_MODIFIED = 0） - 再用
KILL QUERY（而非KILL）终止当前语句，避免触发回滚
命令示例：KILL QUERY 45;（其中 45 是 trx_mysql_thread_id）
终止后必须验证的三个残留点
看似 KILL QUERY 成功，不代表事务真正退出。InnoDB 的事务清理有延迟，尤其在高负载下：
-
INNODB_TRX表中对应trx_id是否彻底消失（需等 1–2 秒后重查） -
SHOW ENGINE INNODB STATUS\G输出中TRANSACTIONS部分是否还有该事务 ID - 检查
innodb_undo_log_truncate是否被阻塞：若Trx id counter长时间不增长，说明 purge 线程被该事务残留阻塞
若发现残留，不要反复 KILL；应检查 information_schema.PROCESSLIST 中该线程是否处于 Sleep 状态且 Command = 'Sleep' —— 这说明客户端已断开，MySQL 正在等待超时（由 wait_timeout 控制），此时只需等待即可，强制干预反而可能损坏内部状态。
如何从源头减少这类事务发生
多数失控长事务源于应用层未正确管理连接生命周期。最有效的防护不是事后 kill，而是前置约束：
- 在 MySQL 层设
max_execution_time = 30000（单位毫秒），对非事务性查询自动超时 - 应用连接池配置
maxLifetime和idleTimeout，避免连接长期空闲却不释放事务上下文 - 禁止应用代码中裸写
BEGIN；所有事务必须包裹在明确的try/finally { conn.rollback() }或使用框架事务模板 - 定期巡检脚本中加入：
SELECT COUNT(*) FROM information_schema.INNODB_TRX WHERE TRX_STARTED
最容易被忽略的是：即使设置了 autocommit = 1，显式 BEGIN 之后仍会进入事务模式，而很多 ORM 默认开启事务却忘记 commit —— 这类“静默事务”才是生产环境长事务的主力来源。
