1分钟了解，预写日志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）以及预写日志，来进行刷盘和数据恢复呢？让你来设计，你会怎么做？

上一篇《刷盘，还是不刷盘，是一个问题》的阅读好惨淡，技术内容看来确实没啥人看了。大伙帮忙三连支持下，感谢。