先写日志、再刷数据——WAL 如何用顺序写解决原子性、持久性与性能三大难题
《数据库内核原理》第 26 篇：数据库预写日志 WAL 的核心思路。
上一篇《刷盘，还是不刷盘，是一个问题》中我们遇到了哪些问题？
1. 已提交事务+未提交事务的ACID特性怎么保证？
上一篇中遇到的问题，主要是原子性与持久性。
2. 数据库崩溃，怎么实施故障恢复？
3. 每次都刷盘随机写，性能低，怎么提高数据库性能？
正常情况下，不需要每个事务提交，都进行刷盘。
要提升随机写性能，最容易想到的，就是利用高性能的顺序写日志，记录事务中的一些信息，来实现已提交事务的数据“要刷盘”，未提交事务的数据“不刷盘”，以及实现故障恢复。
这个顺序写的日志，记录什么内容呢？
事务中，对数据库的写操作。
如何来标识写操作的时序呢？
每条日志记录会有一个递增的日志序列号（log sequence number，LSN），唯一标识一条日志记录。
还有一种特殊的日志记录，叫检查点（checkpoint）。
检查点记录了某一个时刻，缓冲池（buffer pool）中所有数据页（page）的状态信息。
有了检查点和顺序写日志，我们就可以通过：
1. 重放（redo）已提交事务的操作；
2. 取消（undo）未提交事务的操作；
3. 顺序写替代随机写；
来解决，上面提到的三大难题。
这，就是我们今天要聊的核心技术，预写日志（write-ahead logging，WAL）。
预写日志不仅仅是一种日志，更像是一种模式，一种协议，它要求在进行数据写入操作时，必须先写入操作日志。
预写日志的分层结构是怎么样的？
如同数据的内存-磁盘两层结构一样，为了提升性能，预写日志也分为内存-磁盘两层结构：
1. 内存层：WAL buffer
2. 磁盘层：WAL log file
预写日志会记录哪些信息呢？
还是之前那个事务T1：
1. 开始事务
2. 读取记录A的值（假设A=1）
3. 修改记录A的值（假设修改为2）
4. 提交事务
预写日志首先会记录，T1事务开始：
LSN=0:<T1, BEGIN>
读取A的值是一个读操作，不需要进行记录。
修改记录A的值是一个写操作，需要进行记录，而且要记录修改前的值，与修改后的值，类似于：
LSN=1:<T1, A, 1, 2>
以方便未来进行redo与undo（如上图中的屎黄色1）。
接下来，事务会对缓冲池中的数据进行修改（如上图中的屎黄色2）。
到目前为止，预写日志都还是写在buffer中，并没有刷到磁盘上。
事务提交时，预写日志，以及缓冲池会发生什么？
首先，T1事务提交，也会记录到buffer中：
LSN=2:<T1, COMMIT>
但这样，还远远不够。
预写日志，必须全部从buffer里刷到磁盘上，也就是日志文件中，事务才能标记上“已提交”，并返回给应用程序。
没错，只要预写日志从buffer刷到磁盘，而不需要数据从buffer刷到磁盘，就能返回应用程序，事务提交成功。
至于数据什么时候从buffer刷回磁盘，这取决于缓冲池刷盘策略，例如：隔一段时间异步刷盘（如上图中的屎黄色便签）。
这，就是预写日志的核心思路。
总结与思考：
1. 日志序列号（log sequence number，LSN），唯一标识一条日志记录，递增；
2. 检查点（checkpoint），记录了某一个时刻，缓冲池（buffer pool）中所有数据页（page）的状态信息。
3. 预写日志记录什么核心信息？
– 事务开始
– 事务结束（提交/回滚）
– 事务的写操作，修改前/修改后的值
4. 数据库何时能向应用程序返回“事务成功”？
预写日志刷盘成功之后。
5. 上一篇《刷盘，还是不刷盘，是一个问题》结尾的问题：在数据库返回应用程序事务成功之前，要不要将数据刷回磁盘？
只要有预写日志机制，只需要预写日志刷盘，不需要数据刷盘。
新的场景出现了：如果数据库崩了，怎么利用检查点（checkpoint）以及预写日志，来进行刷盘和数据恢复呢？让你来设计，你会怎么做？
检验一下
检索练习 · WAL 协议
预写日志（WAL）作为一种协议，它的核心要求是什么？
检索练习 · LSN 与检查点
关于 LSN 和 checkpoint，下列哪项描述正确？
检索练习 · 日志内容
预写日志会记录哪些核心信息？
检索练习 · 提交时机
数据库何时能向应用程序返回「事务提交成功」？
预写日志解决了「怎么记」，那数据库崩了之后「怎么恢复」？下一篇：ARIES 算法的分析、Redo、Undo 三阶段。
知其然，知其所以然。思路比结论更重要。