WAL 预写式日志

为什么要先写日志

随机写磁盘极慢，但顺序追加写日志很快。WAL 的策略是：提交事务时只需确保日志已刷盘，数据页可以留在内存中稍后批量写入，这样提交延迟取决于顺序写日志的速度而非随机写数据页的速度。如果系统在数据页写盘前崩溃，重启后可以重放（Redo）WAL 日志来重建丢失的修改——这就是崩溃恢复（Crash Recovery）。

InnoDB 的 WAL 叫 Redo Log，默认存在 ib_logfile0 和 ib_logfile1 两个循环文件里。MySQL 8.0.30 起改为动态扩展的单文件，不再有固定大小限制。[1]

WAL 的延伸应用

WAL 的应用远不止崩溃恢复。PostgreSQL 的流复制（Streaming Replication）就是把 WAL 日志实时传输给备库并重放，实现主从同步——这与 MySQL 的 Binlog 复制思想相似，但 WAL 是物理日志（记录页内字节变化），而 Binlog 的 Row 模式记录的是行级变更。

SQLite 在 3.7.0（2010 年）引入了 WAL 模式（PRAGMA journal_mode=WAL），相比默认的 DELETE 模式，WAL 允许一个写事务和多个读事务并发进行，读写不再互相阻塞，大幅提升了并发读场景的性能。