wal要求日志必须先于数据页落盘，崩溃恢复成立的前提是日志记录比对应数据页修改更早、更可靠写入磁盘；innodb严格遵循该顺序，确保修改前生成redo log并至少进入os缓存（=2）或fsync到磁盘（=1），否则崩溃后无法重做。
WAL要求日志必须先于数据页落盘
崩溃恢复能成立的前提，是日志记录比对应的数据页修改更早、更可靠地写入磁盘。InnoDB 严格遵循这一顺序：任何对 Buffer Pool 中数据页的修改，都必须在修改前生成 Redo Log Record，并确保该日志至少已进入 OS 缓存（innodb_flush_log_at_trx_commit = 2）或已 fsync() 到磁盘（=1）。如果跳过这步直接改内存页，崩溃后就无从得知“改了什么”，重做无依据。
常见错误现象：innodb_flush_log_at_trx_commit = 0 时，事务提交后日志可能还在内存缓冲区，此时断电会导致最近最多 1 秒的已提交事务丢失——这不是 WAL 失效，而是你主动放弃了 WAL 的持久性保障。
- WAL 不是“自动生效”的机制，它依赖正确配置的
innodb_flush_log_at_trx_commit - 即使
Redo Log已刷盘，若对应数据页在刷盘中途被部分写入（Partial Page Write），仅靠 Redo Log 也无法恢复——这就是为什么 InnoDB 还要配DoubleWrite Buffer - 日志写入是追加式顺序 I/O，而数据页写入是随机 I/O；顺序写失败概率低、恢复逻辑简单，这是 WAL 可靠性的物理基础
崩溃恢复只信任最后一条成功落盘的 commit 日志
MySQL 启动时做的第一件事，不是读数据文件，而是扫描 redo log 文件，定位到最后一个已成功 fsync() 的 commit 记录对应的 Lsn（Log Sequence Number）。这个 Lsn 就是“一致性边界”——所有 Lsn ≤ 它的已提交事务，必须能通过重放日志完整还原；所有 Lsn > 它的记录，哪怕数据页已刷盘，也视为未提交，会被 Undo Log 清除。
关键点在于：检查点（Checkpoint）不决定一致性，它只缩小扫描范围。你看到 SHOW ENGINE INNODB STATUS 里 “Log sequence number” 和 “Last checkpoint at” 两个值不相等，是完全正常的；恢复起点永远以实际落盘的 commit 日志为准，而非检查点位置。
- 如果某条
commit日志写了一半就断电（比如只写了 511 字节，不足 512 字节扇区），整个日志记录会被认为无效，其事务不参与 Redo -
abort日志同样计入边界判断：一个事务若写了begin和modify，但abort未落盘，恢复时仍会尝试 Redo，再用Undo Log回滚——所以Undo Log本身也要受 WAL 约束 - 日志文件是循环覆盖的（由
innodb_log_file_size和innodb_log_files_in_group控制），截断日志前必须确认其中不含任何活动事务的未完成记录，否则直接破坏一致性边界
Redo Log 是物理日志，重做必须依赖原始页状态
Redo Log 记录的是“对 page X 的 offset Y 处写入 value Z”这类物理操作，不是 SQL 语句。这意味着它不能脱离原始数据页独立工作：重做时，InnoDB 先加载磁盘上的原始页（哪怕它是旧的、甚至损坏的），再按日志逐条打补丁。这也是为什么 DoubleWrite Buffer 不可省略——若原始页因 Partial Page Write 损坏，Redo Log 就会应用到错误的字节位置，导致数据彻底错乱。
对比 Binlog：后者是逻辑日志或行格式事件，可用于主从复制，但不能用于崩溃恢复；Redo Log 是崩溃恢复唯一可信源，且只在本地实例内有效。
-
Redo Log写入发生在COMMIT之前，而Binlog写入在COMMIT之后，两者靠两阶段提交（2PC）对齐——这是跨日志一致性保障，不是单机崩溃恢复所需 - 日志中不保存字段名、约束、索引结构等元信息，只存页号、偏移、字节数和新值；因此无法用于 DDL 恢复，也不能替代备份
- 如果你用
mysqlbinlog解析redo log，会失败——它们是不同格式、不同用途的二进制文件，redo log只能由 InnoDB 自己解析
真正容易被忽略的是：WAL 的一致性保障，始终绑定在 单个 InnoDB 实例的物理页生命周期 上。它不管主从延迟、不处理分布式事务协调、也不承诺跨机器状态一致。一旦涉及多节点，就必须叠加 Binlog、XA 或外部共识协议——WAL 只负责把这一台机器重启后拉回它自己认可的最后一个安全状态。
