在 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 的事务能力。
