上一篇《刷盤，還是不刷盤，是一個問題》中我們遇到了哪些問題？

(1) 已提交事務+未提交事務的ACID特性怎么保證？

畫外音：上一篇中遇到的問題，主要是原子性與持久性。

(2) 數據庫崩潰，怎么實施故障恢復？

(3) 每次都刷盤隨機寫，性能低，怎么提高數據庫性能？

畫外音：正常情況下，不需要每個事務提交，都進行刷盤。

要提升隨機寫性能，最容易想到的，就是利用高性能的順序寫日志，記錄事務中的一些信息，來實現已提交事務的數據“要刷盤”，未提交事務的數據“不刷盤”，以及實現故障恢復。

這個順序寫的日志，記錄什么內容呢？

事務中，對數據庫的寫操作。

如何來標識寫操作的時序呢？

每條日志記錄會有一個遞增的日志序列號（log sequence number，LSN），唯一標識一條日志記錄。

還有一種特殊的日志記錄，叫檢查點（checkpoint）。

檢查點記錄了某一個時刻，緩沖池（buffer pool）中所有數據頁（page）的狀態信息。

有了檢查點和順序寫日志，我們就可以通過：

• 重放（redo）已提交事務的操作；
• 取消（undo）未提交事務的操作；
• 順序寫替代隨機寫；

來解決，上面提到的三大難題。

這，就是我們今天要聊的核心技術，預寫日志（write-ahead logging，WAL）。

預寫日志不僅僅是一種日志，更像是一種模式，一種協議，它要求在進行數據寫入操作時，必須先寫入操作日志。

預寫日志的分層結構是怎么樣的？

如同數據的內存-磁盤兩層結構一樣，為了提升性能，預寫日志也分為內存-磁盤兩層結構：

• 內存層：WAL buffer
• 磁盤層：WAL log file

預寫日志會記錄哪些信息呢？

還是之前那個事務T1：

• 開始事務
• 讀取記錄A的值(假設A=1)
• 修改記錄A的值(假設修改為2)
• 提交事務

預寫日志首先會記錄，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）以及預寫日志，來進行刷盤和數據恢復呢？讓你來設計，你會怎么做？