在MySQL的InnoDB存储引擎中，undo log承担着事务回滚与多版本并发控制的核心职责。当系统出现事务无法回滚、回滚后数据状态异常或者undo表空间异常膨胀时，本质上都是undo log的写入、清理或读取链路发生了问题。理解其内部结构有助于精准定位故障。
一、undo log的基本工作原理
undo log是InnoDB在修改数据页之前，先将数据的旧版本写入undo段的一种机制。每一次UPDATE或DELETE操作，都会生成对应的undo记录，并通过回滚指针（roll_ptr）串联成版本链。如果事务执行ROLLBACK，引擎会沿着版本链将数据还原到事务开始前的状态。
在MySQL 5.7及以后版本中，undo log可以存放在独立的undo表空间（由innodb_undo_tablespaces控制），也可以放在系统表空间。当事务提交后，undo log并不会立刻删除，而是先标记为可 purge，由后台 purge 线程异步清理。如果 purge 跟不上写入速度，就会出现undo空间持续增长的现象。
二、常见undo log问题分类
实际运维中，undo log相关故障通常分为三类。第一类是长事务导致undo无法 purge，因为一致性读需要保留旧版本；第二类是undo表空间物理损坏或参数配置错误；第三类是并发压力之下purge线程性能不足，造成回滚段堆积。
我们可以通过下面这张表快速对照症状与可能原因：
| 现象 | 可能原因 | 排查入口 |
|---|---|---|
| 回滚耗时极长 | undo版本链过长 | innodb_trx、undo pages |
| ibdata或undo文件过大 | purge滞后 | innodb_metrics |
| 回滚报错或数据未还原 | undo段损坏 | 错误日志、checksum |
三、使用系统视图排查undo状态
第一步应当观察当前活跃事务和undo使用情况。通过information_schema.INNODB_TRX可以看到哪些事务长时间未提交，它们会直接阻塞undo的清理。配合performance_schema中的相关指标，能算出undo生成速率。
以下语句可列出运行超过60秒且未提交的事务，这些往往是undo膨胀的元凶：
SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS run_seconds, trx_query FROM information_schema.INNODB_TRX WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60 ORDER BY run_seconds DESC;
接着查看undo相关的度量值，确认purge是否健康。下面的查询展示了undo表空间页的使用情况：
SELECT name, subsystem, COUNT(*) AS metric_count, SUM(value) AS total_value FROM information_schema.INNODB_METRICS WHERE name LIKE '%undo%' GROUP BY name, subsystem;
四、从日志与参数定位物理问题
如果怀疑undo段损坏，应优先检查MySQL错误日志中是否出现“undo log”或“rollback segment”相关的异常记录。InnoDB在启动时会对undo进行校验，一旦发现checksum不匹配会拒绝恢复。
参数层面，需要确认innodb_undo_log_truncate是否开启，以及innodb_purge_rseg_truncate_frequency的设置。当undo表空间过大时，开启 truncate 可让其在超过阈值后自动收缩。示例配置如下：
[mysqld] innodb_undo_tablespaces=2 innodb_undo_log_truncate=ON innodb_max_undo_log_size=1G innodb_purge_rseg_truncate_frequency=128
五、处理长事务与回滚异常
遇到回滚卡死，可先通过KILL命令终止持有的长事务，释放回滚段压力。但需注意，KILL本身也会触发回滚动作，若undo链过长同样缓慢，此时应耐心等待并监控rollback进度。
对于业务侧，应避免在事务中穿插远程调用或人工审核环节。下面这段伪代码展示了错误用法：
// 错误示例：事务内等待外部接口，导致undo长期不释放 conn.setAutoCommit(false); updateAccount(conn, 100); callRemoteRiskService(); // 可能耗时数分钟 conn.commit();
正确做法是将事务压缩到纯数据库操作，把外部交互移到事务之外：
// 正确示例：先完成业务校验，再开启短事务
boolean ok = callRemoteRiskService();
if (ok) {
conn.setAutoCommit(false);
updateAccount(conn, 100);
conn.commit();
}
六、purge线程调优思路
当确认是purge跟不上写入时，可适当提高innodb_purge_threads数量，让清理更并行。同时降低innodb_purge_batch_size的单个批次成本，避免大事务回滚时purge被饿死。
在写入高峰场景，还可以借助监控脚本定时采集undo页面数，一旦超过警戒线就报警。这样能在用户感知前介入，防止回滚异常演变为实例不可用。
排查undo log问题，核心是先分清是“逻辑上删不掉”还是“物理上坏了”，前者靠事务治理，后者靠参数与恢复。