Redo日志是InnoDB实现崩溃恢复的核心物理日志，保障已提交事务的持久性；它记录数据页的底层物理修改并以LSN标识，通过重启后重放确保磁盘数据与提交状态一致。
Redo日志（重做日志）是InnoDB存储引擎实现崩溃恢复（crash recovery）的核心机制，它的本质是一份“物理修改记录”，专门用来确保已提交事务的**持久性（Durability）**——哪怕数据库突然断电或崩溃，重启后也能把那些“内存中改了、但还没写到磁盘”的数据补全。
Redo日志记录什么？
它不记录SQL语句，也不记录逻辑变化（比如“age从28改成30”），而是记录最底层的物理操作，例如：
- “系统表空间第100号页，偏移量1024处的4个字节，由0x1C003F2A改为0x1C003F32”
- “在用户表的索引页#572中，插入一条聚簇索引记录，键值为(1001, 'Alice')”
每条日志都带有一个唯一标识——日志序列号（LSN），用于精确匹配数据页当前状态。
为什么需要Redo日志？
直接把每次更新都刷盘太慢（16KB一页，只改1字节也要写整页；随机IO开销大）。所以InnoDB采用“先写日志、再改内存、异步刷盘”的策略。但这就带来风险：事务已提交，内存数据也改了，可脏页还没落盘，此时崩溃 → 数据丢失。
Redo日志就是这个风险的兜底方案：只要日志已落盘（且标记为commit），哪怕崩溃，重启时也能按日志把缺失的修改重放一遍。
崩溃恢复时Redo日志怎么工作？
MySQL重启后，InnoDB自动进入恢复流程，关键步骤包括：
- 定位起点：从Redo日志文件头读取red">last_checkpoint_lsn，确定哪些日志是“可能未应用”的
- 扫描并过滤：逐条读取Redo日志，跳过LSN ≤ 对应数据页当前LSN的日志（说明该修改已落地）
- 重放（Replay）：对LSN更大的日志，直接将修改应用到Buffer Pool中的对应数据页
- 刷盘同步：后续由后台线程将这些“重做后”的脏页真正写入磁盘表空间
整个过程无需人工干预，完全自动完成，目标是让磁盘数据最终与Redo日志中“已提交事务”的最终状态严格一致。
它和Undo日志、Binlog有什么区别？
三者分工明确：
- Redo Log：引擎层物理日志，保障崩溃后“不丢已提交的数据”，用于前滚（roll-forward）
- Undo Log：引擎层逻辑/物理混合日志，支撑事务回滚和MVCC，用于回退（roll-back）或构造一致性视图
- Binlog：Server层逻辑日志，面向复制与归档，不参与崩溃恢复，但通过两阶段提交与Redo Log协同保证主从/备份一致性
简单说：Redo管“崩溃后怎么补上”，Undo管“出错时怎么撤回”，Binlog管“怎么同步给别人”。
