undo log表空间持续增长的典型现象是history list length长期高于100万且不回落，伴随undo文件（如undo001）超几十gb、磁盘使用率飙升至95%+；根本原因是长事务未提交阻塞purge线程，导致历史版本无法回收，必须先终止源头事务，再按序执行截断流程。
undo log表空间持续增长的典型现象
MySQL 8.0默认启用独立undo表空间（innodb_undo_tablespaces），当事务长时间未提交、大事务回滚卡住，或应用存在长事务未释放时，ibtmp1 和 undo 文件（如 undo<em>001</em>）会持续膨胀。常见表现包括：df -h 显示磁盘使用率突然飙升至95%+，ls -lh /var/lib/mysql/undo* 发现单个文件超几十GB，且 SHOW ENGINE INNODB STATUS\G 中 History list length 值长期高于 100 万。
关键判断依据不是“有没有undo文件”，而是“历史记录是否堆积”——只要这个值不回落，undo就无法被真正回收。
确认undo是否真为罪魁祸首
不要直接删文件。先用以下命令交叉验证：
- 查当前活跃事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60;—— 找出运行超1分钟的事务，重点关注TRX_STATE = 'RUNNING'但TRX_ROWS_MODIFIED > 10000的 - 看undo空间使用情况：
SELECT NAME, FILE_SIZE, ALLOCATED_SIZE FROM performance_schema.files_instances WHERE NAME LIKE '%undo%'; - 检查历史列表长度：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_history_list_length';—— 若稳定在 500k 以上且不降，基本锁定问题 - 对比磁盘增长时间点与慢查询日志中长事务起始时间是否吻合（
/var/log/mysql/slow.log）
注意：innodb_undo_log_truncate 开启后也不会立即收缩文件，它只在满足条件（如空闲undo表空间+超过innodb_max_undo_log_size）时触发异步截断，且需配合innodb_undo_tablespaces ≥ 2才生效。
安全收缩undo表空间的操作顺序
MySQL 8.0 不支持在线 shrink undo 文件，必须分步释放空间：
- 先设法终止源头：杀掉长事务（
KILL <code>trx_mysql_thread_id;），或让应用主动提交/回滚；若事务已卡死，可能需重启，但务必先确认无主从延迟风险 - 确保
innodb_undo_log_truncate = ON（默认开启），并检查innodb_max_undo_log_size（默认1073741824字节 ≈ 1GB）是否合理；若业务常有大事务，可临时调高至2G，避免频繁触发截断开销 - 手动触发一次清理：
SET GLOBAL innodb_undo_log_truncate = OFF; SET GLOBAL innodb_undo_log_truncate = ON;—— 这会强制InnoDB重新评估哪些undo表空间可被截断 - 观察
Innodb_history_list_length是否开始下降；等降到 10k 以内后，undo文件才会真正变小（通常需数分钟到数小时，取决于I/O压力）
切记：不能直接 rm undo_* 或清空 ibtmp1，这会导致实例启动失败。MySQL只在 shutdown 时清理 ibtmp1，而 undo_*.ibd 必须由 InnoDB 自己管理。
预防undo再次撑爆磁盘
根本解法不在“缩”，而在“控”：
- 在应用层加事务超时控制（如 Spring 的
@Transactional(timeout = 30)），避免事务无限期挂起 - 定期巡检：
SELECT NOW(), TRX_ID, TRX_STARTED, TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) AS duration FROM information_schema.INNODB_TRX ORDER BY duration DESC LIMIT 5;加入监控脚本 - 禁用隐式提交陷阱：确认
autocommit = 1（默认），避免开发者手动BEGIN后忘记COMMIT - 对批量更新/删除操作，拆成每1000行一批，并在批次间
COMMIT，防止单事务生成巨量undo
最易被忽略的一点：innodb_undo_tablespaces 设为 2 以上不只是为了高可用，更是为了 truncate 机制能工作——如果只有1个undo表空间，InnoDB永远不敢动它，因为没备用空间可切换。
