Redo Log 是 InnoDB 实现崩溃恢复的核心物理日志，通过 WAL 机制确保已提交事务修改不丢失；其顺序写入、循环复用及前滚+回滚两阶段恢复机制保障数据一致性和高效性。
Redo Log 是 SQL 数据库（尤其是 InnoDB 存储引擎）实现崩溃恢复（Crash Recovery）的核心机制。它通过记录所有已提交事务的物理修改，确保数据库在意外宕机后能重放（Replay）这些变更，从而将数据恢复到一致、最新的状态。
Redo Log 的本质：顺序写入的物理日志
Redo Log 不是 SQL 语句或逻辑操作，而是对数据页（Page）的物理变更描述，例如“将 page 123 的 offset 48 处的 4 字节从 0x11223344 改为 0x55667788”。这种设计带来两个关键优势：
- 日志写入是严格顺序的，远比随机写数据文件快；
- 恢复时只需按序扫描并应用，无需解析事务依赖或回滚未提交事务（那是 Undo Log 的职责）。
崩溃发生时，Redo Log 如何保障数据不丢？
数据库通过 Write-Ahead Logging（WAL）原则强制约束：任何数据页的修改落盘前，对应的 Redo Log 必须先持久化到磁盘（默认由 innodb_flush_log_at_trx_commit 控制）。这意味着：
- 若事务已 commit，其 Redo Log 肯定已在磁盘上（只要该参数设为 1）；
- 即使数据页还停留在 Buffer Pool 或 OS 缓存中未刷盘，重启后也能靠 Redo Log 把这些修改“补上”；
- 未 commit 的事务产生的 Redo 日志也会被写入，但恢复阶段会结合 Undo Log 回滚其影响——Redo Log 本身只负责“重做”，不判断事务状态。
MySQL 启动时的崩溃恢复三步走
实例异常终止后，InnoDB 在启动时自动触发恢复流程，核心步骤如下：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 定位起点：读取 Redo Log 文件头中的 checkpoint LSN（Log Sequence Number），确定哪些日志可能尚未应用；
- 前滚（Redo Phase）：从 checkpoint 开始顺序扫描 Redo Log，解析每条记录，将对应的数据页从磁盘加载进 Buffer Pool，并应用变更（即使页当前不在内存中，也会预读加载）；
- 回滚（Undo Phase）：前滚完成后，扫描 Undo Log 段，对未完成的事务执行逆向操作（如插入变删除、更新还原旧值），确保 ACID 中的原子性与一致性。
几个易混淆点说明
Redo Log ≠ Binlog：前者是 InnoDB 引擎层物理日志，用于本地崩溃恢复；后者是 Server 层逻辑日志，用于主从复制和 PITR（时间点恢复），两者无直接替代关系。
Redo Log 文件不是无限增长：它采用循环覆写方式（ring buffer），由 checkpoint 推进清理边界；若写入速度持续超过 checkpoint 刷盘速度，会导致“Redo Log too large”等待，进而拖慢事务提交。
恢复速度取决于 Redo Log 量，而非数据总量：一次宕机后，如果期间只产生了 10MB Redo 日志，哪怕数据库有 1TB 数据，恢复也只需重放这 10MB —— 这正是 WAL 设计高效的关键。
