在 MySQL 的 InnoDB 存储引擎中，Undo Log 扮演着「数据时光机」的角色。它不仅是事务回滚的基石，更是 MVCC（多版本并发控制）得以实现的关键。很多开发者对 Redo Log 了如指掌，却对 Undo Log 的运作机制一知半解。今天，我们就从底层原理到生产实践，彻底拆解这个支撑高并发事务的核心组件。

一、Undo Log 的三大核心使命

Undo Log 本质上是一种逻辑日志，它记录的是数据被修改前的旧值。与记录物理页修改的 Redo Log 不同，Undo Log 关注的是「如何把数据改回去」。这种设计让它同时承担了三个关键角色：

1. 事务回滚的「后悔药」

当事务执行过程中遇到 ROLLBACK 指令，或者因死锁、异常而中断时，InnoDB 需要一种机制把数据恢复到事务开始前的状态。Undo Log 就是这颗「后悔药」。

举个例子：假设我们执行一条更新语句，将某行记录的 name 字段从 'old' 改为 'new'。此时 Undo Log 会记录下旧值 'old'。一旦事务回滚，InnoDB 直接用 'old' 覆盖 'new'，数据便回到了修改前的样子。整个过程无需依赖备份，完全由日志驱动。

这种逆向操作的能力，是事务原子性（Atomicity）的根本保障。没有 Undo Log，事务回滚将无从谈起。

2. MVCC 的「历史版本仓库」

这是 Undo Log 最容易被低估的能力。在并发场景下，读事务不希望被写事务阻塞，写事务也不应阻塞读事务。MVCC 正是为此而生，而它的底层依赖就是 Undo Log 构建的版本链。

当写事务修改一行数据时，InnoDB 不会直接覆盖旧数据，而是：

  • 生成一个新版本的数据行；
  • 通过隐藏字段 DB_ROLL_PTR 指向 Undo Log 中的旧版本；
  • 读事务根据隔离级别（如 REPEATABLE READ），沿着版本链回溯，找到符合条件的历史版本。

整个过程读事务不加锁，写事务也不阻塞读，这就是 InnoDB 高并发能力的秘密武器。相比 PostgreSQL 的 MVCC 实现，InnoDB 将旧版本存储在 Undo Log 中而非数据页内，这种设计在空间管理上更加灵活，但也带来了 Undo Log 膨胀的风险。

3. 崩溃恢复的「清道夫」

MySQL 崩溃重启后，InnoDB 需要处理那些「已写入 Redo Log 但尚未提交」的事务。这些事务的数据修改可能已经部分落盘，必须被回滚。此时 Undo Log 再次登场：

  1. 分析 Redo Log，识别处于 Prepare 状态但未 Commit 的事务；
  2. 对这些事务执行 Undo Log 中的反向操作；
  3. 清理完成后，释放对应的 Undo Log 空间。

这一流程确保了崩溃恢复后数据的一致性，是 ACID 中 Durability 和 Consistency 的重要支撑。

二、不同操作的 Undo Log 记录规则

Undo Log 并非千篇一律地记录所有旧值，而是根据操作类型采取差异化的记录策略。核心原则是：最小化记录，满足回滚需求即可。

操作类型Undo Log 记录内容回滚逻辑
INSERT待删除的行标识直接删除插入行（仅当前事务可见）
DELETE被删除行的完整旧值重新插入该行，恢复数据
UPDATE被修改列的旧值将列值恢复为旧值
SELECT无记录不修改数据，无需回滚

关键注意：

操作不会产生 Undo Log，只有写操作（INSERT/DELETE/UPDATE）才会触发日志生成。

从表中可以看出，Insert 操作的回滚只需删除对应记录，因此 Undo Log 中仅需记录主键信息；而 Update 操作若涉及索引列变更，还需要额外记录索引的旧值，以便回滚时恢复索引结构。这种精细化的设计，既保证了回滚的正确性，又避免了日志空间的浪费。

值得一提的是，MongoDB 等 NoSQL 数据库在事务实现上采用了截然不同的思路，通常依赖副本集和 WiredTiger 的 MVCC 机制，没有与 InnoDB Undo Log 完全对应的组件。这也从侧面反映了关系型数据库在事务一致性上的工程复杂度。

[AFFILIATE_SLOT_1]

三、Undo Log 如何驱动 MVCC 版本链？

MVCC 的核心思想是「读不加锁，写不阻塞读」。听起来很美好，但实现起来需要一套精密的版本管理机制。Undo Log 构建的版本链，正是这套机制的基础设施。

版本链的生成过程

假设事务 A 执行了一条更新语句，将某行 name 从 'old' 改为 'new'：

  • InnoDB 为该行创建新版本，存储 'new'；
  • 同时生成 Undo Log，记录旧版本 'old'；
  • 新版本的 DB_ROLL_PTR 指向 Undo Log 中的旧版本，形成链式结构。

如果后续还有其他事务继续修改这行数据，版本链会不断延长，每个旧版本都通过指针串联起来。

读事务的版本追溯

当事务 B 执行查询时，如果事务 A 尚未提交，事务 B 会根据隔离级别决定读取哪个版本。在 REPEATABLE READ 下，事务 B 会通过 DB_ROLL_PTR 沿版本链回溯，找到事务 B 开始时刻对应的可见版本，即 'old'。整个过程无需等待事务 A 提交，实现了非锁定读。

这种机制的妙处在于：读操作和写操作互不干扰，极大提升了并发吞吐量。但代价是 Undo Log 需要保留足够长的历史版本，这也是长事务成为「性能杀手」的根本原因。

四、崩溃恢复中的 Undo Log 工作流

MySQL 崩溃后的恢复过程，是 Undo Log 与 Redo Log 协同作战的经典场景。整个流程可以概括为三个阶段：

  1. 分析阶段：InnoDB 扫描 Redo Log，识别所有处于「Prepare 状态但未 Commit」的事务。这些事务的数据修改可能已经部分写入磁盘，必须被回滚。
  2. 回滚阶段：对每个未提交事务，执行 Undo Log 中的反向操作。例如，插入操作回滚为删除，更新操作回滚为旧值。这个过程是幂等的，即使恢复过程中再次崩溃，重启后仍能继续完成。
  3. 清理阶段：回滚完成后，删除这些事务对应的 Undo Log，释放磁盘空间。

⚠️ 需要注意的是，崩溃恢复的时间长短与 Undo Log 的体量直接相关。如果存在大量长事务，恢复过程可能耗时数分钟甚至更久，严重影响数据库的可用性。

五、Undo Log 生产实践与优化指南

理解了原理，接下来看看如何在生产环境中用好 Undo Log。以下是几条经过验证的最佳实践：

1. 独立存储，减少 IO 竞争

将 Undo Log 存放在独立的 SSD 磁盘上，避免与数据文件、Redo Log 共享存储设备。这样可以显著减少 IO 争用，提升整体吞吐量。

# 配置文件 my.cnf
innodb_undo_directory = /ssd/undo_log  # 指定独立存储目录
在这里插入图片描述

2. 控制日志大小，防止膨胀

Undo Log 膨胀是生产环境中的常见问题。可以通过以下配置进行控制：

  • 使用 innodb_max_undo_log_size 限制单个 Undo 表空间的大小，默认值为 1G；
  • 开启自动截断功能，定期清理不再需要的过期日志。
innodb_undo_log_truncate = ON  # 开启自动截断（默认开启）
innodb_max_undo_log_size = 512M  # 调整单个表空间最大大小
在这里插入图片描述

3. 杜绝长事务，从源头控制

长事务是 Undo Log 膨胀的头号元凶。因为 MVCC 需要保留历史版本供其他事务读取，长事务会导致 Undo Log 无法及时清理，进而引发一系列问题：

  • Undo Log 体积持续增长，占用大量磁盘空间；
  • 回滚时间变长，影响数据库性能；
  • 崩溃恢复时间显著增加。

建议将事务拆分为短事务，单次事务耗时控制在 10 秒以内。同时避免在事务中执行 SELECT ... FOR UPDATE 等长时间锁定操作。对于必须处理大批量数据的场景，可以考虑分批提交，或者使用 Redis 等缓存层来减轻数据库压力。

✅ 另外，定期监控 information_schema.INNODB_TRX 表，及时发现并处理运行时间过长的事务，是 DBA 日常巡检的重要工作。

[AFFILIATE_SLOT_2]

总结

Undo Log 作为 InnoDB 的核心日志组件，通过记录数据修改前的旧值，同时支撑了事务回滚、MVCC 和崩溃恢复三大能力。理解其工作原理，不仅能帮助我们排查并发场景下的疑难问题，更能通过合理配置（如独立存储、控制长事务、开启自动截断）来优化数据库性能。掌握 Undo Log，是迈向 MySQL 高阶开发者的必经之路。

SELECT