WAL是SQL数据库底层持久化与崩溃恢复的核心机制，要求日志必须先于数据页修改落盘，以此保障ACID中的原子性与持久性，并通过顺序写提升性能、支撑复制。
SQL 数据库中的 WAL（Write-Ahead Logging，预写式日志）不是某种可选插件，而是一种底层持久化与崩溃恢复机制的核心设计思想。它的核心原则非常朴素：任何数据页的修改，必须先将该修改对应的日志记录（log record）安全写入磁盘（即“日志先行”），之后才允许更新内存中的数据页，更不允许直接刷脏页到磁盘。
日志先于数据落盘
这是 WAL 最根本的体现。比如执行一条 UPDATE users SET name = 'Alice' WHERE id = 100：
- 数据库不会立刻去磁盘上找到 users 表的对应数据页并改写；
- 而是先在内存中生成一条结构化日志：「在 users 表第 X 页、槽位 Y 处，将旧 name 字段值 'Bob' 改为 'Alice'」；
- 这条日志被追加写入 WAL 文件（如 PostgreSQL 的
pg_wal/，MySQL InnoDB 的ib_logfile*），且必须调用 fsync 确保落盘； - 只有日志落盘成功后，内存中的缓冲页（buffer pool / shared_buffers）才被标记为“已修改”，后续 checkpoint 或刷盘时再写回数据文件。
支持原子性与持久性（ACID 中的 A 和 D）
WAL 是事务原子提交和崩溃后数据不丢失的关键支撑：
- 事务提交（COMMIT）时，只需确保其所有日志记录已 fsync 到 WAL 文件——无需等待关联的数据页刷盘，因此提交极快；
- 若系统崩溃，重启时数据库读取 WAL：对已提交但未刷盘的数据页，重做（Redo）日志操作；对已写日志但未提交的事务，撤销（Undo）其影响（通常借助额外的 undo log 或回滚段）；
- 整个过程不依赖数据文件的完整性，只要 WAL 文件完整，就能重建一致状态。
解耦写入性能与持久性保障
WAL 把随机写（更新不同表/页）转化为顺序写（日志追加），大幅提升写吞吐：
- 数据文件更新是离散、随机的，而 WAL 是 append-only，适合 SSD/HDD 的顺序写特性；
- 多个事务的日志可批量 fsync（例如 PostgreSQL 的
wal_writer_delay+wal_writer_flush_after），进一步摊薄 I/O 开销； - 后台进程（如 checkpointer、page cleaner）可异步、按需刷脏页，避免前台事务阻塞。
支撑主从复制与逻辑订阅
WAL 不仅服务本地恢复，也是外部消费变更的基础：
- PostgreSQL 的物理复制：备库直接接收并重放主库的 WAL 流；
- 逻辑复制（如
pgoutput协议）：从 WAL 中解析出逻辑变更（INSERT/UPDATE/DELETE），转换为逻辑消息分发； - MySQL 的 binlog 虽非严格 WAL（它在引擎层之上），但设计目标类似：提供可靠、有序的变更序列用于复制与审计。
WAL 思想的本质，是用一份轻量、有序、只追加的“操作账本”，替代对原始数据的频繁、随机、高风险直接修改。它让数据库在性能、可靠性、扩展性之间取得关键平衡。
