大事务导致Undo Log暴涨的根本原因是其阻塞purge线程，使History list length飙升；因MVCC要求未提交事务的旧版本数据必须保留，trx_state='RUNNING'且trx_query IS NULL的空闲事务最危险，MySQL 5.7默认共享undo表空间（ibdata1）且innodb_undo_log_truncate无效，kill后undo文件不缩是因回滚与purge需时间，ibdata1空间不可收缩。
大事务本身不直接“导致”Undo Log暴涨，而是它让InnoDB的MVCC机制无法释放旧版本数据——只要事务没提交，所有它修改过的行的旧快照就必须保留，对应undo记录就一直不能被purge线程清理。
为什么大事务会让History list length飙升
History list length不是磁盘占用值，而是“等待被purge的undo记录总数”。一个运行10分钟的UPDATE事务，可能修改数万行，每行变更都会生成至少一条undo记录；而只要该事务仍处于trx_state = 'RUNNING'，这些记录就全被钉住。其他并发事务的读请求（尤其是REPEATABLE READ隔离级别）还会进一步延长保留时间。
-
TRX_ROWS_MODIFIED > 0且duration_sec > 300的事务是主要贡献者 - 只读事务（
TRX_ROWS_MODIFIED = 0）也会持有ReadView，但不新增undo，影响相对小 -
trx_query IS NULL的“空闲RUNNING”事务最危险：它不干活，却长期霸占快照
MySQL 5.7默认配置加剧了这个问题
5.7默认使用共享undo表空间（ibdata1），且innodb_undo_log_truncate在该模式下完全不生效——你根本没法对ibdata1里的undo做在线截断。同时，innodb_max_purge_lag若设为0或过大，purge线程会彻底躺平，History list length只会单向增长。
-
innodb_file_per_table = OFF时，所有undo都挤进ibdata1，文件只增不减 -
innodb_undo_tablespaces = 0（5.7默认），意味着独立undo表空间未启用，innodb_undo_log_truncate形同虚设 -
innodb_purge_batch_size默认仅300，面对海量undo清理效率极低
为什么kill掉大事务后undo文件还不缩
即使你立刻KILL了那个大事务，undo也不会马上消失。回滚（rollback）本身要写undo、刷磁盘、更新页，这个过程可能持续几分钟；之后purge线程才开始清理它留下的历史记录。而5.7的ibdata1一旦膨胀，就无法收缩——你看到的文件大小不会回落，只是内部空间被标记为可复用。
- 执行
KILL后，观察SHOW ENGINE INNODB STATUS\G中PURGE DONE是否推进，而非看du -sh ibdata1 -
History list length从几万降到几百通常需要数十秒到数分钟，取决于IO压力和innodb_purge_batch_size设置 - 别尝试
ALTER TABLE ... ENGINE=InnoDB来“重建表”释放ibdata1空间——无效，它仍会往里写
真正卡住undo回收的，往往不是那个正在跑的大UPDATE，而是它旁边一个trx_state = 'RUNNING'、trx_query IS NULL、已空闲8小时的应用连接。查INNODB_TRX必须带ORDER BY trx_started，盯最老的那个。
