redo log 保证事务持久性，记录物理修改用于崩溃恢复；undo log 保证原子性和一致性，记录逻辑反操作用于回滚和 MVCC。
在 MySQL 中，redo log 和 undo log 是 InnoDB 存储引擎实现事务持久性和原子性的核心机制。它们分工明确，作用不同，理解它们有助于掌握 MySQL 事务背后的运行原理。
redo log：保证事务的持久性
redo log（重做日志） 记录的是“物理层面”数据页的修改，比如“某个数据页上某偏移量写入了哪些字节”。它的主要作用是确保事务提交后，即使数据库宕机，已提交的数据也不会丢失。
InnoDB 引擎采用 WAL（Write-Ahead Logging）技术，即“先写日志，再写数据”。当执行一条更新语句时：
- 先把修改操作记录到 redo log 中，并将日志状态设为“prepare”
- 随后事务提交时，redo log 被标记为“commit”
- 实际的数据页修改可以异步刷盘，不需立即完成
如果系统崩溃重启，InnoDB 会读取 redo log，把已提交但未写入磁盘的更改重新应用，从而恢复数据。
redo log 是循环写入的，大小固定（由 innodb_log_file_size 控制），适合高性能顺序写，避免频繁随机写数据文件带来的性能损耗。
undo log：保证事务的原子性和一致性
undo log（回滚日志） 记录的是“逻辑操作”的反向操作，用于回滚事务或提供多版本并发控制（MVCC）。
例如，执行一条 DELETE 操作，undo log 会记录一条对应的 INSERT；执行 UPDATE，则记录旧值以便回退。
它的主要用途包括：
- 事务执行过程中出错或执行 ROLLBACK，可通过 undo log 恢复到事务开始前的状态
- 支持 MVCC，让不同事务看到数据的不同版本，提升并发性能
undo log 存储在 undo 表空间中，生命周期与事务相关，长期未提交的事务会导致 undo 日志无法清理，可能引发空间膨胀。
两者的关键区别
- 目的不同：redo log 保障“已提交事务不丢”，undo log 保障“未提交事务可回滚”
- 内容不同：redo log 是物理日志，记录页的修改；undo log 是逻辑日志，记录行的旧值
- 写入时机不同：redo log 在事务提交前写入磁盘（WAL）；undo log 在事务执行过程中生成，提交后可能被标记删除
- 存储方式不同：redo log 循环使用；undo log 按事务组织，后期通过 purge 清理
简单类比帮助理解
可以把数据库操作想象成写文章：
- redo log 像是自动保存的“修改快照”，即使电脑突然断电，重启后也能根据它恢复已保存的内容
- undo log 像是“撤销功能”，当你写错一段文字想退回上一步，系统可以根据它还原之前的状态
基本上就这些。redo log 和 undo log 各司其职，一个保“持久”，一个保“原子”，共同支撑起 InnoDB 的事务能力。
