【MySQL】Undo Log 深度解析：事务回滚与 MVCC 的底层支柱
在 InnoDB 存储引擎中，Undo Log 是保障事务一致性与并发性能的核心组件。它作为「逻辑日志」记录数据修改前的状态，不仅支撑着事务回滚、崩溃恢复等基础能力，更是多版本并发控制（MVCC）实现的关键。本文将从作用、原理、实践三个维度，带你彻底搞懂 Undo Log。
一、Undo Log 的三大核心能力
Undo Log 的设计目标是解决「数据修改的可逆性」与「并发访问的隔离性」，核心作用可概括为三点：
1. 事务回滚的「时光机」
当事务执行 ROLLBACK 或因异常中断时，InnoDB 会通过 Undo Log 逆向操作，将数据恢复到事务开始前的状态。例如：
- 执行
UPDATE user SET name='test' WHERE id=1后，Undo Log 记录name的旧值； - 回滚时直接用旧值覆盖新值，实现数据回退。
2. MVCC 的「历史版本库」
多事务并发时，读事务无需等待写事务提交，而是通过 Undo Log 读取数据的历史版本，实现「非锁定读」。这也是 InnoDB 高并发能力的核心：
- 写事务修改数据时，会生成新数据版本，并通过
roll_pointer指向 Undo Log 中的旧版本； - 读事务根据隔离级别（如
REPEATABLE READ），通过版本链追溯符合条件的历史版本，避免锁竞争。
3. 崩溃恢复的「数据守护者」
MySQL 崩溃后重启，InnoDB 会通过 Undo Log 清理未提交的事务：
- 分析 Redo Log 识别未提交事务；
- 执行 Undo Log 的反向操作（如插入回滚为删除、更新回滚为旧值）；
- 确保重启后数据一致性。
二、不同操作的 Undo Log 记录规则
Undo Log 会根据操作类型差异化记录，核心原则是「最小化记录，满足回滚需求」：
| 操作类型 | Undo Log 记录内容 | 回滚逻辑 |
| INSERT | 待删除的行标识 | 直接删除插入行（仅当前事务可见） |
| DELETE | 被删除行的完整旧值 | 重新插入该行，恢复数据 |
| UPDATE | 被修改列的旧值 | 将列值恢复为旧值 |
| SELECT | 无记录 | 不修改数据，无需回滚 |
- INSERT 操作：记录「删除该插入行」的逻辑（因插入的行仅当前事务可见，回滚时直接删除即可）。
- DELETE 操作：记录「重新插入该删除行」的逻辑（回滚时需恢复被删除的行，因此记录行的完整旧值）。
- UPDATE 操作：记录「将修改后的列恢复为旧值」的逻辑（如
update user set name='test' where id=1，Undo Log 记录name的旧值，回滚时将name改回旧值）。
关键注意：
SELECT操作不会产生Undo Log，只有写操作（INSERT/DELETE/UPDATE）才会触发日志生成。
三、Undo Log 如何支撑 MVCC？
MVCC 的核心是「读不加锁，写不阻塞读」，其底层依赖 Undo Log 构建的「版本链」：
1. 版本链生成流程
- 事务 A 执行
UPDATE user SET name='new' WHERE id=1（原name为 ‘old’）； - InnoDB 为该行创建新版本（存储 ‘new’），并生成 Undo Log 记录旧版本（’old’）；
- 新版本的
roll_pointer指向 Undo Log 中的旧版本，形成链式结构。
2. 读事务的版本追溯
- 事务 B 执行
SELECT name FROM user WHERE id=1（隔离级别REPEATABLE READ）； - 若事务 A 未提交，事务 B 会通过
roll_pointer追溯 Undo Log 中的旧版本，读取到 ‘old’； - 无需等待事务 A 提交，实现非锁定读。
四、崩溃恢复中的 Undo Log 工作流
MySQL 崩溃后，InnoDB 会通过以下步骤完成恢复：
- 分析 Redo Log：识别所有处于「Prepare 状态但未 Commit」的事务；
- 执行 Undo 回滚：对每个未提交事务，执行 Undo Log 中的反向操作；
- 清理日志：回滚完成后，删除这些事务的 Undo Log，释放磁盘空间。
五、Undo Log 最佳实践（性能优化 + 避坑指南）
1. 独立存储，提升 IO 性能
将 Undo Log 存储在 SSD 磁盘，避免与数据文件、Redo Log 共享存储，减少 IO 竞争：
# 配置文件 my.cnf
innodb_undo_directory = /ssd/undo_log # 指定独立存储目录
2. 控制日志大小，避免膨胀
- 通过
innodb_max_undo_log_size限制单个 Undo 表空间大小（默认 1G）； - 开启自动截断功能，定期清理过期日志：
innodb_undo_log_truncate = ON # 开启自动截断（默认开启）
innodb_max_undo_log_size = 512M # 调整单个表空间最大大小
3. 禁止长事务，减少日志占用
长事务会持续占用 Undo Log（需保留历史版本供 MVCC 访问），导致：
- Undo Log 体积膨胀，占用磁盘空间；
- 回滚时间变长，影响数据库性能。
建议：
- 将事务拆分为短事务，单次事务耗时控制在 10 秒内；
- 避免在事务中执行
SELECT FOR UPDATE等长时间锁定操作。
总结
Undo Log 作为 InnoDB 的核心日志组件，通过记录数据修改前的状态，同时支撑了事务回滚、MVCC、崩溃恢复三大核心能力。理解其工作原理，不仅能帮助我们排查并发场景下的问题，更能通过合理配置（如独立存储、控制长事务）优化数据库性能。
如果觉得本文有帮助、对文中内容有疑问，欢迎留言交流～ 后续将继续分享 MySQL 日志体系的其他组件，敬请关注！
