长事务卡住undo日志回收的根本原因是未提交，导致InnoDB必须保留旧版本供MVCC快照读，进而引发undo空间膨胀、purge停滞、锁长期持有及SELECT变慢。
短事务不是“建议”，而是 MySQL 正常运转的底线要求；长事务会卡住 undo 日志回收、拖死 purge 线程、让锁一直不放，最终连 SELECT 都变慢。
长事务为何卡住 undo 日志回收
undo 日志不能被 purge 线程清理，根本原因不是“时间长”，而是它没提交——只要事务还活跃，InnoDB 就得保留它开始前所有数据的旧版本，供其他事务做 MVCC 快照读。这会导致：
-
innodb_undo_tablespaces磁盘空间持续上涨，甚至填满（尤其开启innodb_undo_log_truncate=ON但无活跃事务触发 truncate 时） - 历史版本链变长，
SELECT扫描 undo 链耗时增加，information_schema.INNODB_TRX里trx_started时间越久，影响越明显 - purge 线程忙于跳过这些“钉子事务”对应的记录，实际清理进度停滞，
SHOW ENGINE INNODB STATUS中可见Purge done for trx's n:o < [low watermark]长期不推进
锁为什么迟迟不释放
InnoDB 的行锁、间隙锁（Gap Lock）和 Next-Key Lock 全部绑定在事务生命周期上，不是语句执行完就释放。一个未提交的事务哪怕只执行了一条 UPDATE users SET status=1 WHERE id=123，它持有的锁就会一直挂着：
- 其他事务想更新同一行？
Waiting for lock直接卡住 - 想插入
id=122或id=124？间隙锁可能拦住，引发幻读防护级阻塞 - DDL 操作（如
ALTER TABLE）会被卡在Waiting for table metadata lock，因为元数据锁需要所有活跃事务释放才能获取 - 监控里
innodb_row_lock_time_avg和innodb_row_lock_waits会明显跳升
如何快速定位正在作祟的长事务
别等报警，日常就得查。以下命令直击要害：
SELECT trx_id, trx_mysql_thread_id AS thread_id, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
重点关注 duration_sec > 60 的记录，结合 trx_state 判断是否卡在外部调用或慢查询上。如果 trx_query 是 NULL，说明事务处于空闲状态（比如应用层开了事务但忘了提交），此时 KILL [thread_id] 通常能立即生效；若状态是 ROLLING BACK，只能等——改 innodb_fast_shutdown 也没用。
真正管用的防御手段不在数据库侧
监控和 KILL 是兜底，防不住人为失误。关键要从应用层掐断源头：
- 禁止在事务里做 HTTP 调用、文件读写、sleep、复杂计算——这些操作不产生数据库日志，却白白占着锁和 undo
- ORM 层（如 MyBatis、GORM）避免隐式开启长事务，检查
@Transactional注解作用域是否过大 - 批量更新必须分页提交，单次事务控制在 1000 行以内，配合
innodb_lock_wait_timeout=50防雪崩 - 连接池配置需匹配事务预期时长，比如 HikariCP 的
connection-timeout和max-lifetime要略大于最长业务事务，避免连接被池误杀导致事务悬挂
最易被忽略的一点：即使全是只读 SELECT，显式开启事务（BEGIN）也会创建 read view 并加入活跃事务链表——这种“伪长事务”在报表类场景中大量存在，一样拖慢 purge 和内存回收。
