redo log 记录物理页修改以保证持久性，崩溃时重放恢复；undo log 记录逻辑前像以保证原子性和一致性，用于回滚和MVCC快照读。
redo log 记录“做了什么”，保证事务持久性；undo log 记录“原本是什么”，保证事务原子性和一致性。
redo log：崩溃恢复的物理日志
redo log 是 InnoDB 存储引擎特有的、基于物理页的循环写入日志，用于确保已提交事务的数据不因宕机而丢失。它记录的是“某数据页在某个偏移量上被修改成了什么值”，属于前滚日志（crash recovery 时重放）。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 写入时机：事务执行过程中，修改缓冲池（Buffer Pool）后立即写入 redo log（遵循 Write-Ahead Logging，WAL），无需等待刷盘到数据文件
- 存储位置：独立于表空间的物理日志文件（如 ib_logfile0、ib_logfile1），大小固定、循环复用
- 作用核心：MySQL 崩溃重启后，InnoDB 通过重放 redo log 中已提交但未落盘的修改，把数据恢复到最新一致状态
undo log：实现回滚与多版本并发控制（MVCC）的逻辑日志
undo log 是逻辑日志，记录的是“某条记录被修改前的样子”，比如 INSERT 对应一条逻辑上的 DELETE，UPDATE 对应一条反向的 UPDATE（恢复旧值）。它不直接参与崩溃恢复，而是服务于事务回滚和快照读。
- 写入时机：事务开始修改数据前，先将原始版本写入 undo log（分配 undo segment，生成 undo record）
- 存储位置：位于共享表空间或独立 undo 表空间（5.6+ 可配置）中的 undo pages，按事务生命周期管理
- 两个主要用途：
– 回滚：事务执行 ROLLBACK 时，用 undo log 恢复到修改前状态
– MVCC：SELECT 语句根据 read view 和 undo log 链找到对应版本的快照数据，实现非锁定读
关键区别对比
方向相反：redo log 向前重放（replay），undo log 向后回退（rollback）；
内容不同：redo 是物理页变更（如“page 5, offset 108, 改为 0x1234”），undo 是逻辑行变更（如“id=100 的 name 从 'Alice' 变为 'Bob'，原值是 'Alice'”）；
生命周期不同：redo log 在 checkpoint 推进后可覆盖重用，undo log 必须保留至所有依赖它的事务（包括长事务、正在做快照读的事务）结束才能清理。
