首先检查长时间未提交的事务，使用SELECT * FROM information_schema.INNODB_TRX和SHOW ENGINE INNODB STATUS\G定位活跃事务；接着查看undo表空间大小及使用情况，通过information_schema.FILES和操作系统命令确认文件增长；然后分析purge滞后情况，关注“History list length”值，确保purge线程正常运行并调整innodb_purge_threads等参数提升效率；最后优化大事务和长查询，避免读视图长期持有，必要时启用innodb_undo_log_truncate=ON自动截断undo表空间。
MySQL中的undo log主要用于事务的回滚和多版本并发控制（MVCC）。当出现undo log相关问题时，比如事务执行缓慢、长时间未提交、磁盘空间占用高，甚至错误日志中提示与undo表空间相关的异常，就需要进行排查。以下是常见的排查思路和方法。
检查长时间运行的事务
长时间未提交的事务会阻止MySQL清理undo log，导致undo表空间持续增长。
可以通过以下语句查看当前活跃事务：
- SELECT * FROM information_schema.INNODB_TRX; — 查看当前正在运行的InnoDB事务，重点关注trx_started时间较早的事务。
- SHOW ENGINE INNODB STATUS\G — 在输出中的“TRANSACTIONS”部分查看活跃事务详情，包括事务状态、开始时间、持有的锁等。
如果发现某个事务长时间未提交，需联系应用方确认是否正常，必要时可使用KILL [thread_id]终止该连接。
监控undo表空间使用情况
MySQL 8.0之后使用了独立的undo表空间（默认为undo_001, undo_002…），可通过以下方式查看其大小和使用状态：
- 查询系统表空间和undo文件路径：SELECT NAME, SPACE_TYPE, FILE_NAME FROM information_schema.FILES WHERE SPACE_TYPE = 'Undo';
- 结合操作系统命令查看实际文件大小：ls -lh /var/lib/mysql/undo*
如果undo文件持续增大，说明历史记录无法被清理，通常是因为存在“最老的活跃读视图”（oldest active read view）未释放。
分析purge线程是否滞后
InnoDB通过purge操作清理已提交事务的undo日志。若purge速度跟不上事务生成速度，会导致undo堆积。
可通过以下方式判断purge是否滞后：
- 执行SHOW ENGINE INNODB STATUS\G，查看“History list length”值。该值表示等待purge的undo record数量，若长期大于几千甚至上万，说明purge滞后。
- 检查InnoDB后台线程状态，确认purge线程是否正常运行。
提高purge效率的方法包括：
- 调整innodb_purge_threads（建议设为4以提升并行度）。
- 增加innodb_io_capacity和innodb_max_dirty_pages_pct，加快后台刷脏和清理速度。
优化大事务和长查询
大事务或执行时间很长的select（尤其是未使用索引的）会持有读视图，阻止undo日志回收。
建议做法：
- 避免在事务中处理大量数据，拆分为小事务提交。
- 检查慢查询日志，定位执行时间长的SQL，优化其执行计划。
- 监控是否有长时间运行的只读事务或一致性读（consistent read）。
可通过设置innodb_undo_log_truncate=ON，配合innodb_undo_tablespaces和阈值参数，启用自动truncate undo表空间（MySQL 8.0支持）。
基本上就这些。关键在于及时发现长事务、监控history list长度、确保purge机制正常运转，并合理配置undo管理策略。undo log问题往往不是突然爆发，而是逐渐积累，日常监控很重要。
