与直接写入“真实数据库”相比，是什么使得写入“WAL”要快得多？

Question

如果我理解正确的话，PostgreSQL 是这样工作的：

1. 我对 PG 数据库中的表进行 INSERT、DELETE 或 UPDATE 查询。
2. PG 立即以原始（内部）日志的形式（可能是二进制格式）将此查询及其参数写入 HDD/SSD。
3. 假设该表足够小，可以存储在 RAM 中，PG 现在会插入/删除/更新此“RAM 表”以反映更改，但实际上并不更改数据库文件。
4. 在稍后的某个时间点，也许是几秒钟，也许是几分钟，甚至可能是几小时或几天后，当它“有时间”时，PG 使用此“WAL”日志文件中的信息更新数据库文件，并删除相关行（ s)/WAL 日志文件中的条目。

对于这个看似奇怪的仪式，我得到的解释是，对于每个查询，写入 WAL 比直接写入数据库文件要快得多。

但这是为什么呢？我认为 PG 的 WAL 日志文件比仅仅“在文本文件末尾添加行”更复杂，因为这可能会导致两个查询同时写入它，从而丢失或损坏数据。所以它必须比这更复杂。这意味着更多的开销。此时我想知道这样做有什么真正的性能优势，因为归根结底，这两者都涉及写入速度较慢的 HDD/SSD 磁盘。

不过，我并不怀疑这一点。我只是想知道为什么它这么快。

在我看来，写入数据库文件的问题与写入 WAL 的问题相同。在这两种情况下，您都需要确保它有序且正确地完成。我唯一的猜测是，也许各种约束检查之类的查找成本很高。

显然，“WAL”的概念是 PostgreSQL 所独有的，但至少对已执行的查询保留某种“选项卡”，以解决断电和软件崩溃问题，这听起来只是常识。每次只是盲目地写入数据库文件，甚至不保留任​​何类型的日志，这听起来像是一场灾难，我无法想象任何数据库曾经这样做过。想象一下，如果有人在断电时进行了 100 万美元的交易，然后他们的账户损失了 100 万美元，但另一个人却没有收到任何钱！即使是 20 世纪 40 年代的数据库软件也可能不是这样工作的……

Answer 1

您在阅读文档时一定错过了答案：

使用 WAL 会显着减少磁盘写入次数，因为只需将日志文件刷新到磁盘即可保证事务提交，而不需要事务更改的每个数据文件。日志文件是按顺序写入的，因此同步日志的成本远低于刷新数据页的成本。对于处理涉及数据存储不同部分的许多小事务的服务器来说尤其如此。此外，当服务器正在处理许多小的并发事务时，日志文件的一次 fsync 可能足以提交许多事务。