查长事务需查INFORMATION_SCHEMA.INNODB_TRX表，关注TRX_STARTED超60秒、TRX_STATE='RUNNING'且TRX_ROWS_LOCKED>1000、TRX_WAITING_TRX_ID非NULL；优先用KILL TRANSACTION TRX_ID终止事务，配合ROLLBACK；推荐用pt-kill自动监控而非手写脚本。
查长事务：用 INFORMATION_SCHEMA.INNODB_TRX 看实时锁占用
MySQL 不会主动告诉你哪个事务卡住了，得自己去翻内存里的运行时状态。最直接的入口是 INFORMATION_SCHEMA.INNODB_TRX 表，它记录了每个活跃事务的开始时间、状态、锁等待情况。
常见错误现象：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 返回空？别急——可能你没权限，或者事务已提交但锁还没释放（比如在 COMMIT 前被 kill 了）；也可能是只读事务不进这个表。
- 重点看
TRX_STARTED和当前时间差，超过 60 秒就值得怀疑 -
TRX_STATE = 'RUNNING'且TRX_ROWS_LOCKED > 1000是高风险信号 -
TRX_WAITING_TRX_ID非 NULL，说明它正被另一个事务堵着，得顺藤摸瓜查源头
杀事务：用 KILL TRANSACTION 还是 KILL QUERY？
别一上来就 KILL 进程 ID（CONNECTION_ID），容易误杀整个连接，尤其当应用用了连接池——一个连接里可能跑着多个逻辑请求。
优先用 KILL TRANSACTION <code>TRX_ID（MySQL 5.7+ 支持），它只终止事务本身，保留连接复用；如果版本太老（如 5.6），只能退而求其次用 KILL QUERY <code>ID，但要注意这会中断当前语句，事务仍处于 active 状态，除非显式 ROLLBACK。
-
KILL TRANSACTION不会触发自动回滚，需配合监控脚本在 kill 后补一句ROLLBACK（通过同连接执行） - 用
KILL前先SELECT TRX_MYSQL_THREAD_ID FROM INFORMATION_SCHEMA.INNODB_TRX拿到线程 ID，再KILL更稳妥 - 避免在高峰期批量
KILL，可能引发大量锁重试和 CPU 尖峰
自动监控：用 pt-kill 而不是手写定时 SQL
自己写 SELECT ... FROM INNODB_TRX + KILL 脚本看似简单，实际容易漏掉并发竞争、权限失效、SQL 注入（如果拼接了用户输入）、以及 kill 后状态未及时刷新等问题。
pt-kill（Percona Toolkit）是经过生产验证的方案，它内置重试、连接复用、安全过滤，还能按匹配条件（如 user、db、state、time）精准筛选。
- 命令示例：
pt-kill --busy-time 60 --kill --victims all --match-command Query --ignore-user system - 注意
--victims all会杀所有匹配事务，上线前务必先加--print预览 - 它默认不杀
SLEEP状态连接，但长事务常表现为Query或Locked，所以要明确指定--match-state
为什么事务会长时间不结束？重点盯 autocommit=0 和应用层异常
数据库本身不会“忘记”提交，所有长事务都是应用行为导致的：要么显式关了 autocommit 后忘了 COMMIT，要么出错没走 catch 里的 ROLLBACK，要么网络断开后连接挂起，事务还卡在服务端。
最容易被忽略的是 ORM 的隐式事务行为，比如 Django 的 transaction.atomic() 块里抛了未捕获异常，或 Golang 的 sql.Tx 忘记调 Rollback() / Commit()。
- 在 MySQL 配置里加
wait_timeout=300和interactive_timeout=300只能断连，不能终止事务——InnoDB 事务生命周期独立于连接 - 应用日志里搜
"BEGIN"和"COMMIT"不成对出现的位置，比查数据库更快定位问题模块 - 监控报警阈值别设成固定 300 秒，要结合业务特征：报表类事务允许 5 分钟，但订单支付类超过 10 秒就得告警
事情说清了就结束
