pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
预写式日志（WAL）是事务日志记录的标准方法。大多数（即使不是全部）事务处理书籍中都能找到详细描述。简而言之， WAL 的核心思想是，对数据文件（即表和索引所在之处）的更改， 必须在这些更改被记入日志之后才能写出；也就是说，必须在描述这些更改的日志 记录被刷入永久存储之后，再去写数据文件。如果遵循这个过程，就无需在每次事务 提交时都把数据页刷盘，因为我们知道，一旦发生崩溃，就可以利用日志恢复数据 库：任何尚未应用到数据页上的更改，都可以根据日志记录重做。（这就是前滚恢 复，也称 REDO。）
使用 WAL 的第一个主要优势是显著减少磁盘写入次数，因为在事务提交时只需把日志文件刷入磁盘，而不必刷写该事务更改过的每个数据文件。在多用户环境中，许多事务的提交可以通过对日志文件的一次 fsync 完成。此外，日志文件是顺序写入的，因此同步日志的代价远低于刷写数据页。对于处理大量小事务、且这些事务触及数据存储不同部分的服务器，这一点尤其明显。
下一个优势是数据页的一致性。事实是，在 WAL 出现之前， PostgreSQL 从未能保证崩溃情况下的一致性。在 WAL 之前，写入期间的任何崩溃都可能导致：
索引问题（问题 1 和 2）也许可以通过额外的 fsync 调用来修复，但如果没有 WAL，如何处理最后一种情况并不明显。必要时，WAL 会把整个数据 页内容保存到日志中，以确保崩溃后恢复的页面一致性。
最后，WAL 使在线备份和时间点恢复成为可能，如 第 22.3 节 所述。通过归档 WAL 数据，我们就能支 持回退到可用 WAL 数据覆盖范围内的任意时刻：只需先安装数据库的一个较早物理 备份，然后把 WAL 重放到目标时刻即可。更进一步说，这个物理备份不必是数据库 状态的瞬时快照 — 即使备份是在一段时间内完成的，重放这段时间内的 WAL 也能修复任何内部不一致。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。