应查information_schema.INNODB_TRX中TRX_STATE='RUNNING'且TRX_STARTED超时的事务，TRX_QUERY为空仍可能持锁，需结合TRX_MYSQL_THREAD_ID关联PROCESSLIST定位静默挂起线程。
如何识别正在阻塞其他事务的长事务
MySQL 中真正造成锁等待的，往往不是“锁本身”，而是持有锁却迟迟不提交的事务。最直接的判断方式是查 information_schema.INNODB_TRX 表，重点关注 TRX_STATE = 'RUNNING' 且 TRX_STARTED 时间过早的记录。
执行这条语句能快速定位嫌疑长事务：
SELECT TRX_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY, TRX_STARTED,
UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(TRX_STARTED) AS trx_seconds
FROM information_schema.INNODB_TRX
WHERE TRX_STATE = 'RUNNING'
AND (UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(TRX_STARTED)) > 60
ORDER BY trx_seconds DESC;注意：TRX_QUERY 可能为 NULL（比如事务只做了 DML 但还没执行语句），不能仅靠它判断是否“空闲”。重点看 trx_seconds 和 TRX_MYSQL_THREAD_ID。
- 如果
TRX_QUERY是NULL且trx_seconds超过 5 分钟，大概率是应用端没调用COMMIT或ROLLBACK -
TRX_MYSQL_THREAD_ID可用于关联information_schema.PROCESSLIST查看客户端 IP、用户、命令状态 - 避免依赖
SHOW PROCESSLIST，它不显示事务起始时间，也看不到隐式开启的事务
为什么 innodb_lock_wait_timeout 对长事务无效
这个参数只控制「等待锁的事务」最多等多久，不是控制「持有锁的事务」能活多久。也就是说：A 事务持锁 2 小时，B 事务去更新同一行，B 最多等 innodb_lock_wait_timeout 秒（默认 50）就会报错 Lock wait timeout exceeded，但 A 仍继续挂着——超时机制完全不作用于 A。
所以不能指望调大这个值来“缓解”问题，反而可能让阻塞更隐蔽、更难发现。
- 调大
innodb_lock_wait_timeout只会让 B 等得更久，不解决 A 的问题 - 真正有效的手段是监控并主动 kill 长事务，而不是延长等待容忍度
- 部分 ORM（如 Django 的
atomic块、Spring 的@Transactional）在异常未被捕获时可能漏掉 rollback，这类场景最容易产生静默长事务
如何安全地终止长事务而不中断业务
直接 KILL 线程有风险：若该事务已写入大量数据，回滚会消耗 IO 和时间，期间仍占着锁。优先确认它是否真有必要被杀——比如先查它是否还在活跃执行：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = <code>TRX_MYSQL_THREAD_ID</code>;
观察 COMMAND 是否为 Sleep、STATE 是否为空、TIME 是否持续增长。如果是，基本可判定是应用端卡住或忘记提交。
- 用
KILL <code>TRX_MYSQL_THREAD_ID终止连接，InnoDB 会触发回滚；不要用KILL QUERY，它只中断当前语句，事务仍存在 - 生产环境建议加一层确认：比如只 kill
TIME > 300 AND COMMAND = 'Sleep'的连接 - 对关键业务线程（如订单服务），最好先通过应用日志或链路追踪确认其状态，再操作
如何从源头减少长事务发生
监控和 kill 是兜底，真正要降低发生率，得约束应用行为。MySQL 本身不提供“事务最大存活时间”强制限制，但可通过组合策略实现：
- 在应用层设置数据库连接的
wait_timeout和interactive_timeout（比如设为 300），让空闲连接自动断开，从而间接终结其事务（注意：需确保应用能正确重连和处理连接失效） - 使用
SET SESSION innodb_lock_wait_timeout = 10缩短单次等待上限，让阻塞更快暴露，便于监控告警 - 在 ORM 层统一包装事务逻辑，加入超时检测（例如 Spring 的
timeout属性），超时后主动抛异常并触发 rollback - 禁止在事务中做 HTTP 调用、文件读写、循环 sleep 等耗时操作——这些是长事务最常见的成因
事务不是“越长越稳”，而是越长越危险。很多锁等待问题，根源不在并发模型，而在一行没提交的 START TRANSACTION 后面，跟着一个忘了写的 COMMIT。
