前段時間我在準(zhǔn)備暑期實(shí)習(xí)嘛，這是當(dāng)時面攜程的時候二面的一道問題，我一臉懵逼，趕緊道歉，不好意思不知道沒了解過，面試官又解釋說 redo log，我尋思著 redo log 我知道啊，WAL 是啥？

給面試官整無語了（滑稽），為我當(dāng)時的無知道歉。后來回去百度了一下才知道，最近又在丁奇大佬的《MySQL 實(shí)戰(zhàn) 45 講》 中看到了 WAL，遂來寫篇文章總結(jié)下。

InnoDB 體系架構(gòu)在說 WAL 之前，有必要簡單介紹下 InnoDB 存儲引擎的體系架構(gòu)，方便我們理解下文，并且 redo log 也是 InnoDB 存儲引擎所特有的。

如下圖，InnoDB 存儲引擎由內(nèi)存池和一些后臺線程組成：

內(nèi)存池

先來解釋下內(nèi)存池。

首先，我們需要知道，InnoDB 存儲引擎是基于磁盤存儲的，并將其中的記錄按照頁的方式進(jìn)行管理。因此可將其視為基于磁盤的數(shù)據(jù)庫系統(tǒng)（Disk-base Database），在這樣的系統(tǒng)中，眾所周知，由于 CPU 速度與磁盤速度之間的不匹配，通常會使用緩沖池技術(shù)來提高數(shù)據(jù)庫的整體性能。

所以這里的內(nèi)存池也被稱為緩沖池（簡單理解為緩存就好了）。

具體來說，緩沖池其實(shí)就是一塊內(nèi)存區(qū)域，在 CPU 與磁盤之間加入內(nèi)存訪問，通過內(nèi)存的速度來彌補(bǔ)磁盤速度較慢對數(shù)據(jù)庫性能的影響。

擁有了緩沖池后，“讀取頁” 操作的具體步驟就是這樣的：

首先將從磁盤讀到的頁存放在緩沖池中

下一次再讀相同的頁時，首先判斷該頁是否在緩沖池中。若在緩沖池中，稱該頁在緩沖池中被命中，直接讀取該頁。否則，讀取磁盤上的頁。

“修改頁” 操作的具體步驟就是這樣的：

首先修改在緩沖池中的頁；然后再以一定的頻率刷新到磁盤上。

所謂 ”臟頁“ 就發(fā)生在修改這個操作中，如果緩沖池中的頁已經(jīng)被修改了，但是還沒有刷新到磁盤上，那么我們就稱緩沖池中的這頁是 ”臟頁“，即緩沖池中的頁的版本要比磁盤的新。

至此，綜上所述，我們可以得出這樣的結(jié)論：緩沖池的大小直接影響著數(shù)據(jù)庫的整體性能。

后臺線程

后臺線程其實(shí)最大的作用就是用來完成 “將從磁盤讀到的頁存放在緩沖池中” 以及 “將緩沖池中的數(shù)據(jù)以一定的頻率刷新到磁盤上” 這倆個操作的，當(dāng)然了，還有其他的作用。以下是《MySQL 技術(shù)內(nèi)幕：InnoDB 存儲引擎 - 第 2 版》對于后臺線程的描述：

后臺線程的主要作用就是刷新內(nèi)存池中的數(shù)據(jù)，保證內(nèi)存池中緩存的是最近的數(shù)據(jù)；此外將已修改的數(shù)據(jù)文件刷新到磁盤文件，同時保證在數(shù)據(jù)庫發(fā)生異常的情況下 InnoDB 能恢復(fù)到正常運(yùn)行狀態(tài)。

另外，InnoDB 存儲引擎是多線程的模型，也就是說它擁有多個不同的后臺線程，負(fù)責(zé)處理不同的任務(wù)。這里簡單列舉下幾種不同的后臺線程：

Master Thread：主要負(fù)責(zé)將緩沖池中的數(shù)據(jù)異步刷新到磁盤，保證數(shù)據(jù)的一致性

IO Thread：在 InnoDB 存儲引擎中大量使用了 AIO（Async IO）來處理寫 IO 請求，這樣可以極大提高數(shù)據(jù)庫的性能。IO Thread 的工作主要是負(fù)責(zé)這些 IO 請求的回調(diào)（call back）處理

Purge Thread：回收已經(jīng)使用并分配的 undo 頁

Page Cleaner Thread：將之前版本中臟頁的刷新操作都放入到單獨(dú)的線程中來完成。其目的是為了減輕原 Master Thread 的工作及對于用戶查詢線程的阻塞，進(jìn)一步提高 InnoDB 存儲引擎的性能

redo log 與 WAL 策略上文我們提到，當(dāng)緩沖池中的某頁數(shù)據(jù)被修改后，該頁就被標(biāo)記為 ”臟頁“，臟頁的數(shù)據(jù)會被定期刷新到磁盤上。

倘若每次一個頁發(fā)生變化，就將新頁的版本刷新到磁盤，那么這個開銷是非常大的。并且，如果熱點(diǎn)數(shù)據(jù)都集中在某幾個頁中，那么數(shù)據(jù)庫的性能將變得非常差。另外，如果在從緩沖池將頁的新版本刷新到磁盤時發(fā)生了宕機(jī)，那么這個數(shù)據(jù)就不能恢復(fù)了。

所以，為了避免發(fā)生數(shù)據(jù)丟失的問題，當(dāng)前事務(wù)數(shù)據(jù)庫系統(tǒng)（并非 MySQL 所獨(dú)有）普遍都采用了 WAL（Write Ahead Log，預(yù)寫日志）策略：即當(dāng)事務(wù)提交時，先寫重做日志（redo log），再修改頁（先修改緩沖池，再刷新到磁盤）；當(dāng)由于發(fā)生宕機(jī)而導(dǎo)致數(shù)據(jù)丟失時，通過 redo log 來完成數(shù)據(jù)的恢復(fù)。這也是事務(wù) ACID 中 D（Durability 持久性）的要求。

有了 redo log，InnoDB 就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。

舉個簡單的例子，假設(shè)你非常熱心且 rich 的，借出去了很多錢，但是你非常 old school，不會使用電子設(shè)備并且記性不太好，所以你用一個小本本記下了所有欠你錢的人的名字和具體金額。這樣，別人還你錢的時候，你就翻出你的小本本，一頁頁地找到他的名字然后把這次還的錢扣除掉。

但是呢，其實(shí)你平常是非常忙碌的，沒辦法隨時隨地翻小本本做記錄，因此你就想出了一個主意：每當(dāng)有人還你錢的時候，你就在一張白紙上記下來，然后挑個時間對照小本本把白紙上的賬目都給清了。

這就是 WAL。白紙就是 redo log，小本本就是磁盤。

當(dāng)然了，redo log 可不是白紙這么簡單，一張用完了換一張就行了，這里有必要詳細(xì)解釋下。

每個 InnoDB 存儲引擎至少有 1 個重做日志文件組（ redo log group），每個文件組下至少有 2 個重做日志文件（redo log file），默認(rèn)的話是一個 redo log group，其中包含 2 個 redo log file：ib_logfile0 和 ib_logfile1 。

一般來說，為了得到更高的可靠性，用戶可以設(shè)置多個鏡像日志組（mirrored log groups），將不同的文件組放在不同的磁盤上，以此提高 redo log 的高可用性。在日志組中每個 redo log file 的大小一致，并以循環(huán)寫入的方式運(yùn)行。

所謂循環(huán)寫入，也就是為啥我們說 redo log 不像白紙那樣用完一張換一張就行，舉個例子，如下圖，一個 redo log group，包含 3 個 redo log file：

InnoDB 存儲引擎會先寫 redo log file 0，當(dāng) file 0 被寫滿的時候，會切換至 redo log file 1，當(dāng) file 1 也被寫滿時，會切換到 redo log file 2 中，而當(dāng) file 2 也被寫滿時，會再切換到 file 0 中。

可以看出，redo log file 的大小設(shè)置對于 InnoDB 存儲引擎的性能有著非常大的影響：

redo log file 不能設(shè)置得太大，如果設(shè)置得很大，在恢復(fù)時可能需要很長的時間

redo log file 又不能設(shè)置得太小了，否則可能導(dǎo)致一個事務(wù)的日志需要多次切換重做日志文件

CheckPoint 技術(shù)有了 redo log 就可以高枕無憂了嗎？顯然不是這么簡單，我們?nèi)匀幻媾R這樣 3 個問題：

1）緩沖池不是無限大的，也就是說不能沒完沒了的存儲我們的數(shù)據(jù)等待一起刷新到磁盤

2）redo log 是循環(huán)使用而不是無限大的（也許可以，但是成本太高，同時不便于運(yùn)維），那么當(dāng)所有的 redo log file 都寫滿了怎么辦？

3）當(dāng)數(shù)據(jù)庫運(yùn)行了幾個月甚至幾年時，這時如果發(fā)生宕機(jī)，重新應(yīng)用 redo log 的時間會非常久，此時恢復(fù)的代價將會非常大。

因此 Checkpoint 技術(shù)的目的就是解決上述問題：

緩沖池不夠用時，將臟頁刷新到磁盤

redo log 不可用時，將臟頁刷新到磁盤

縮短數(shù)據(jù)庫的恢復(fù)時間

所謂 CheckPoint 技術(shù)簡單來說其實(shí)就是在 redo log file 中找到一個位置，將這個位置前的頁都刷新到磁盤中去，這個位置就稱為 CheckPoint（檢查點(diǎn)）。

針對上面這三點(diǎn)我們依次來解釋下：

1）縮短數(shù)據(jù)庫的恢復(fù)時間：當(dāng)數(shù)據(jù)庫發(fā)生宕機(jī)時，數(shù)據(jù)庫不需要重做所有的日志，因?yàn)?Checkpoint 之前的頁都已經(jīng)刷新回磁盤。故數(shù)據(jù)庫只需對 Checkpoint 后的 redo log 進(jìn)行恢復(fù)就行了。這顯然大大縮短了恢復(fù)的時間。

2）緩沖池不夠用時，將臟頁刷新到磁盤：所謂緩沖池不夠用的意思就是緩沖池的空間無法存放新讀取到的頁，這個時候 InnoDB 引擎會怎么辦呢？LRU 算法。InnoDB 存儲引擎對傳統(tǒng)的 LRU 算法做了一些優(yōu)化，用其來管理緩沖池這塊空間。

總的思路還是傳統(tǒng) LRU 那套，具體的優(yōu)化細(xì)節(jié)這里就不再贅述了：即最頻繁使用的頁在 LRU 列表（LRU List）的前端，最少使用的頁在 LRU 列表的尾端；當(dāng)緩沖池的空間無法存放新讀取到的頁時，將首先釋放 LRU 列表中尾端的頁。這個被釋放出來（溢出）的頁，如果是臟頁，那么就需要強(qiáng)制執(zhí)行 CheckPoint，將臟頁刷新到磁盤中去。

3）redo log 不可用時，將臟頁刷新到磁盤：

所謂 redo log 不可用就是所有的 redo log file 都寫滿了。但事實(shí)上，其實(shí) redo log 中的數(shù)據(jù)并不是時時刻刻都是有用的，那些已經(jīng)不再需要的部分就稱為 ”可以被重用的部分“，即當(dāng)數(shù)據(jù)庫發(fā)生宕機(jī)時，數(shù)據(jù)庫恢復(fù)操作不需要這部分的 redo log，因此這部分就可以被覆蓋重用（或者說被擦除）。

舉個例子來具體解釋下：一組 4 個文件，每個文件的大小是 1GB，那么總共就有 4GB 的 redo log file 空間。write pos 是當(dāng)前 redo log 記錄的位置，隨著不斷地寫入磁盤，write pos 也不斷地往后移，就像我們上文說的，寫到 file 3 末尾后就回到 file 0 開頭。CheckPoint 是當(dāng)前要擦除的位置（將 Checkpoint 之前的頁刷新回磁盤），也是往后推移并且循環(huán)的：

write pos 和 CheckPoint 之間的就是 redo log file 上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 CheckPoint，就表示 redo log file 滿了，這時候不能再執(zhí)行新的更新，得停下來先覆蓋（擦掉）一些 redo log，把 CheckPoint 推進(jìn)一下。

綜上所述，Checkpoint 所做的事情無外乎是將緩沖池中的臟頁刷新到磁盤。不同之處在于每次刷新多少頁到磁盤，每次從哪里取臟頁，以及什么時間觸發(fā) Checkpoint。在 InnoDB 存儲引擎內(nèi)部，有兩種 Checkpoint，分別為：

Sharp Checkpoint：發(fā)生在數(shù)據(jù)庫關(guān)閉時將所有的臟頁都刷新回磁盤，這是默認(rèn)的工作方式，參數(shù) innodb_fast_shutdown=1

Fuzzy Checkpoin：InnoDB 存儲引擎內(nèi)部使用這種模式，只刷新一部分臟頁，而不是刷新所有的臟頁回磁盤。關(guān)于 Fuzzy CheckPoint 具體的情況這里就不再贅述了。

有了 bin log 為什么還需要 redo log？前文我們講過，MySQL 架構(gòu)可以分成倆層，一層是 Server 層，它主要做的是 MySQL 功能層面的事情；另一層就是存儲引擎，負(fù)責(zé)存儲與提取相關(guān)的具體事宜。

redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，包括錯誤日志（error log）、二進(jìn)制日志（binlog）、慢查詢?nèi)罩荆╯low query log）、查詢?nèi)罩荆╨og）。

其他三個日志顧明思意都挺好理解的，需要解釋的就是 binlog（二進(jìn)制日志，binary log），它記錄了對 MySQL 數(shù)據(jù)庫執(zhí)行更改的所有操作，但是不包括 SELECT 和 SHOW 這類操作，因?yàn)檫@類操作對數(shù)據(jù)本身并沒有修改。也就是說，binlog 是邏輯日志，記錄的是這個語句的原始邏輯，比如 “給 ID=1 這一行的 a 字段加 1”。

可以看出來，binlog 日志只能用于歸檔，因此 binlog 也被稱為歸檔日志，顯然如果 MySQL 只依靠 binlog 等這四種日志是沒有 crash-safe 能力的，所以為了彌補(bǔ)這種先天的不足，得益于 MySQL 可插拔的存儲引擎架構(gòu)，InnoDB 開發(fā)了另外一套日志系統(tǒng) — 也就是 redo log 來實(shí)現(xiàn) crash-safe 能力。

這就是為什么有了 bin log 為什么還需要 redo log 的答案。

回顧下 redo log 存儲的東西，可以發(fā)現(xiàn) redo log 是物理日志，記錄的是 “在某個數(shù)據(jù)頁上做了什么修改”。

另外，還有一點(diǎn)不同的是：binlog 是追加寫入的，就是說 binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志；而 redo log 是循環(huán)寫入的。

編輯：jq