redo log 是 innodb 保障事务持久性的核心机制，通过 wal 先写日志再更新数据页，崩溃后重放日志恢复未刷盘修改；记录物理页变更，顺序写提升性能；刷盘策略由 innodb_flush_log_at_trx_commit 控制；与 binlog 通过两阶段提交保证主从一致；采用循环写机制，空间满时触发 checkpoint 刷脏页。
MySQL 的 redo log 是 InnoDB 实现事务持久性的核心机制，面试中常被深挖原理、刷盘策略、与 binlog/undo log 的协作关系。它不是“日志备份”，而是保障崩溃后数据不丢的刚性能力。
redo log 为什么必须存在
InnoDB 所有写操作都先更新 Buffer Pool（内存），再异步刷脏页到磁盘。但若在脏页落盘前宕机，已提交事务的数据就永久丢失——这直接违反 ACID 中的持久性。redo log 通过 WAL（Write-Ahead Logging）解决该问题：事务提交前，先把“对哪个页、哪个偏移、改了什么字节”这类物理变更记录追加写入顺序的 redo log 文件。即使宕机，重启时只需重放这些日志，就能把未刷盘的修改补上。
关键点：
- redo log 记录的是物理页变更（如“表空间2，页号105，偏移量128，写入4字节新值”），不是 SQL 语句
- 它是 InnoDB 独有，Server 层无感知；binlog 是 Server 层日志，记录逻辑操作
- 顺序写远快于随机写（刷脏页是随机 IO），这是性能与安全兼顾的设计
redo log 刷盘时机与 innodb_flush_log_at_trx_commit 参数
该参数控制事务提交时 redo log 缓冲区（redo log buffer）向磁盘刷写的严格程度，直接影响数据安全性与吞吐量：
- 值为 1：每次 COMMIT 都触发 fsync，确保日志真正落盘。最安全，金融系统必选
- 值为 0：每秒由后台线程统一刷盘一次，崩溃可能丢失 1 秒内已提交事务的数据
- 值为 2：每次 COMMIT 写入操作系统缓存（OS buffer），由 OS 决定何时落盘；MySQL 进程崩溃不丢，但主机断电会丢
生产环境严禁设为 0；设为 2 可用于对一致性要求稍低的读写混合场景；设为 1 是强一致系统的底线配置。
redo log 与 binlog 的两阶段提交（2PC）
MySQL 同时使用 redo log（引擎层）和 binlog（Server 层），为保证主从一致和崩溃恢复逻辑统一，必须协调两者状态。两阶段提交流程如下：
- Prepare 阶段：InnoDB 将 redo log 写入并标记为 prepare 状态，此时事务已具备崩溃恢复能力，但尚未真正提交
- Commit 阶段：Server 层写入 binlog；成功后通知 InnoDB 将 redo log 状态改为 commit
崩溃恢复时判断逻辑：
- 若 redo log 是 prepare 但 binlog 缺失 → 回滚该事务（避免主库有而从库无）
- 若 redo log 是 prepare 且 binlog 存在 → 提交该事务（保证主从数据一致）
这套机制让主库 crash 后能精确恢复，也确保 binlog 可靠用于从库复制或归档。
redo log 的物理结构与循环写机制
redo log 不是无限增长的日志文件，而是固定大小的环形缓冲区（log group），典型配置为 2 个文件 × 每个 48MB（innodb_log_file_size）。内部有两个指针：
- write pos：当前写入位置
- checkpoint：已刷入数据页、可被覆盖的起始位置
当 write pos 追上 checkpoint，说明日志空间将满，InnoDB 会触发 checkpoint，将对应脏页刷盘，并推进 checkpoint 位置。这个过程自动完成，无需人工干预，但若频繁触发 checkpoint，往往意味着 log 文件过小或写压力过大。
