WAL预写日志是什么

WAL预写日志概念与作用

• WAL（Write-Ahead Logging，预写日志）是一种在数据库中保证事务原子性与持久性的机制，遵循“先写日志，再改数据”的原则：对数据页的任何修改，必须先把对应的日志记录持久化到磁盘，之后才允许把脏页刷盘。这样即使发生崩溃/断电，也能通过重做日志把已提交但未落盘的数据恢复，从而维护事务的ACID特性。WAL还能把对数据页的随机写转换为对日志的顺序写，显著降低I/O成本、提升吞吐。

工作流程

• 事务执行时，先在内存中生成对应的日志记录并写入日志缓冲区；在事务提交时，按策略将日志强制刷盘（fsync）。
• 数据页的修改先在缓冲池/缓冲区高速缓存中进行，WAL机制保证在对应的脏页被刷新到磁盘之前，其日志记录已先落盘。
• 后台进程按检查点策略将脏页逐步刷回数据文件，避免日志无限增长并缩短恢复时间。

关键组件与概念

• Redo Log（重做日志）：记录“修改后”的数据页状态，用于崩溃后的重做（Redo），确保已提交事务不丢失。
• Undo Log（回滚日志）：保存“修改前”的数据版本，用于回滚未提交的修改，并支撑MVCC多版本读。
• LSN（Log Sequence Number，日志序列号）：按字节偏移量标识日志写入位置，作为恢复起点与复制进度的度量。
• Checkpoint（检查点）：定期将脏页刷盘，并在日志中写入检查点记录，界定日志可回收边界与恢复起点，减少重启恢复时间。

在不同数据库中的实现

• PostgreSQL：事务日志即WAL，默认存放在**$PGDATA/pg_wal目录，单个段文件默认16MB**；通过LSN标识位置，配合检查点与WAL归档实现崩溃恢复、时间点恢复（PITR）与流复制。
• MySQL（InnoDB）：通过redo log实现WAL，日志顺序写、循环写；提交时依据innodb_flush_log_at_trx_commit策略将日志刷盘，确保持久性；与binlog通过两阶段提交保持一致性。
• SQL Server：采用预写事务日志，在将脏页刷新到磁盘之前，必须先将对应的日志记录写入磁盘；若使用某些IDE SATA磁盘，需启用enable_force_flush以避免缓存导致的一致性风险。

典型应用场景与优势

• 崩溃恢复与高可用：异常重启后可按LSN顺序重做WAL，快速恢复到一致状态；配合复制实现高可用与读写分离。
• 时间点恢复（PITR）：开启WAL归档后，结合基础备份可将数据库恢复到任意时间点，满足合规与运维需求。
• 性能优化：顺序写日志显著优于随机写数据页，降低I/O瓶颈、提升吞吐；同时以检查点控制脏页刷盘频率与日志保留范围。