Redo、Undo 和 Binlog 都记录“变化”，但服务对象不同：Redo 负责 InnoDB 崩溃恢复，Undo 支持回滚与旧版本读取，Binlog 服务复制和按时间点恢复。它们不能互相简单替代。
Table of contents
Open Table of contents
三本不同用途的账
| 日志 | 层次 | 主要用途 |
|---|---|---|
| Redo | InnoDB | 重放已提交但尚未落入数据页的修改 |
| Undo | InnoDB | 回滚未完成修改、构造历史版本 |
| Binlog | MySQL Server | 复制、审计线索、时间点恢复 |
WAL 是 Write-Ahead Logging，先让恢复所需日志满足持久化条件，再允许脏数据页稍后写回。这样提交不必随机刷写许多数据页。
一次提交如何跨越两类日志
事务变更既要进入 InnoDB Redo，也要写入 Server 层 Binlog。MySQL 使用内部提交协调，避免出现存储引擎认为已提交而 Binlog 没有对应事件，或反过来的不一致状态。学习时可以把它理解为“准备—写 Binlog—最终提交”的协调过程，但具体阶段和刷盘行为受版本与配置影响。
innodb_flush_log_at_trx_commit 和 sync_binlog 会影响持久性与吞吐权衡。不要从网上复制高性能配置后直接上线；先明确允许丢失多少已确认事务，再结合硬件缓存、电源保护和故障演练决策。
崩溃恢复不是备份
Redo 能处理进程或主机异常后的页恢复，却不能挽回误删表、逻辑污染或整个存储卷丢失。备份提供独立副本；Binlog 可把全量备份恢复到之后某一时刻；恢复演练证明它们真的可用。
恢复目标要写成 RPO 和 RTO：RPO 是最多能丢多久的数据，RTO 是最多允许服务停多久。没有可验证目标，“已开启日志”不等于可恢复。
下一步
继续阅读06-13 Schema、数据类型与约束，把正确性前移到表结构设计。