Redo Log 必须先写，否则事务提交后数据可能永久丢失：MySQL 先更新 Buffer Pool 缓存页，若宕机时脏页未刷盘且无 redo log，则修改丢失；redo log 以极小物理日志记录变更，支持崩溃后重放恢复，并通过两阶段提交与 binlog 协同保证一致性。
Redo Log 必须先写，否则事务提交后数据可能永久丢失
MySQL 更新操作不是直接刷盘，而是先改 Buffer Pool 中的缓存页。如果事务提交时只把内存改了、没留任何日志就宕机，那这次更新就彻底消失了——因为脏页还没来得及刷到磁盘，而内存一断电就清空。Redo Log 就是为解决这个致命问题而存在的：它用极小体积（比如只记“表空间 3 中第 127 页偏移量 80 处写入值 0x1a”）记录物理变更，确保崩溃后能重放恢复。
为什么不能等 Binlog 写完再提交事务？
Binlog 是 Server 层日志，由执行器生成，依赖事务已成功修改内存的状态；而 Redo Log 是 InnoDB 引擎层日志，必须在引擎完成修改后立刻落盘（prepare 状态）。如果反过来让 Binlog 先写、再写 Redo Log，就会出现不一致风险：
- Binlog 已写入但 Redo Log 还没写，此时崩溃 → 恢复后数据仍是旧值，但 Binlog 里却多了一条“已执行”的逻辑日志，主从同步或恢复时会出错
- Redo Log 写完但 Binlog 没写完就崩溃 → 恢复后数据是新值，但 Binlog 缺失该事件，导致从库无法同步
所以 MySQL 采用两阶段提交（2PC）：redo log prepare → binlog write → redo log commit，靠 Redo Log 的先写和状态标记兜底。
Redo Log 的顺序写特性决定了它必须最先落盘
Redo Log 文件是固定大小、循环覆盖的（如 ib_logfile0 ~ ib_logfile3），写入位置由 write_pos 指针控制，本质是纯顺序追加。相比随机写 16KB 的数据页，写几十字节的 Redo 日志延迟极低、吞吐极高。这也是 WAL（Write-Ahead Logging）机制的核心：用顺序 IO 换取事务响应速度。一旦跳过这步，把压力直接压到 Buffer Pool 刷盘上，innodb_flush_log_at_trx_commit=1 场景下的性能会断崖式下跌。
容易忽略的关键点：Redo Log 不是“可选优化”，而是持久性的强制前提
有人误以为只要调大 innodb_log_file_size 或关掉 sync_binlog 就能绕过 Redo Log 的约束，其实不行。InnoDB 在事务提交路径中硬编码了 Redo Log 的 prepare/commit 流程，哪怕你把 innodb_flush_log_at_trx_commit 设为 0（只写 OS cache），Redo Log 也依然要先生成并进入缓冲区——否则引擎根本不会允许事务进入提交阶段。真正可调的是刷盘时机，而不是是否写入。
