WAL在MySQL中的实现

WAL 在 MySQL 中的实现

一 核心原理与组件

• **WAL（Write-Ahead Logging）**遵循“先写日志、后改数据”的原则：事务提交前，先把修改以日志形式持久化，再异步刷回数据页，从而把随机写数据页转换为顺序写日志，显著提升吞吐并保障崩溃可恢复。MySQL 的 WAL 由 InnoDB 存储引擎实现，核心日志是 redo log；与之配合的还有用于回滚与 MVCC 的 undo log，以及 Server 层的 binlog（用于复制与时间点恢复）。InnoDB 通过 **LSN（Log Sequence Number）**标识日志写入位置，并借助 Checkpoint界定可回收的日志区间与恢复起点。

二 写入路径与关键流程

• 事务执行：在 Buffer Pool 中修改数据页，生成对应的 redo log 记录到 redo log buffer；涉及二级索引的写入可能进入 Change Buffer 暂存，待页读入缓冲池后再合并应用。
• 提交阶段：根据参数 innodb_flush_log_at_trx_commit 决定何时将 redo log 刷盘（见下文“持久性权衡”）。InnoDB 与 Server 层的 binlog 通过“两阶段提交（2PC）”保持一致性：先 prepare InnoDB 事务并写/刷 redo log，再写/刷 binlog，最后 commit 标记事务完成。
• 组提交（Group Commit）：为提高 fsync 效率，多个事务的日志刷盘会被批量合并，显著降低每次提交的 I/O 成本。
• 后台刷脏与检查点：后台线程按策略将脏页刷入数据文件，推进 Checkpoint；Checkpoint 之前的日志可被归档/回收，崩溃恢复则从最近 Checkpoint 起 **按 LSN 顺序重做（Redo）**已提交事务，未提交事务利用 undo log 回滚，从而恢复到一个一致状态。

三 磁盘结构与关键参数

• 磁盘结构与 LSN：InnoDB 的 WAL 是一组固定大小的循环日志文件（常见为 ib_logfile0/1），可通过 innodb_log_file_size 与 innodb_log_files_in_group 配置总容量。每个日志文件前 2048 字节为文件头（含 LOG_CHECKPOINT_1/2 等），随后按 512 字节的日志块（Block）顺序写入；Block 头含 block_number、block_data_len、first_rec_offset、checksum 等字段，LSN 是自日志创建起累计写入的字节数，用于定位日志在文件中的物理位置。
• 持久性权衡（innodb_flush_log_at_trx_commit）：
  • 1：每次提交执行 write + fsync，安全性最高，性能相对较低（推荐用于强一致场景）。
  • 2：每次提交 write 到 OS page cache，不强制 fsync；进程崩溃通常不丢，但断电可能丢（折中方案）。
  • 0：提交时不主动写/刷，依赖后台每秒刷盘；性能最高，宕机可能丢失最近约 1 秒事务（性能优先）。
• 容量与吞吐：若 write pos 追上 checkpoint，表示日志空间将满，需先推进 Checkpoint（刷脏）再继续写入，避免更新被阻塞。

四 与其他日志及复制的关系

• 日志职责边界：
  • redo log（InnoDB）：物理日志，记录“哪个页的哪个偏移被改成什么”，用于崩溃后的 重做，是 WAL 的核心载体。
  • undo log（InnoDB）：逻辑日志，记录“如何撤销本次修改”，用于 回滚 与 MVCC 的版本链。
  • binlog（Server）：逻辑日志，记录事务的 SQL 或行变更，用于 主从复制 与 时间点恢复（PITR）；与 redo log 通过 两阶段提交 保证跨日志的一致性。
• 复制与恢复：基于 binlog 的复制将变更应用到从库；基于 redo log 的崩溃恢复确保本机已提交事务不丢，二者协同构成 MySQL 的高可用与可恢复基础。