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

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

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

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

內(nèi)存池

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

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

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

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

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

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

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

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

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

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

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

后臺(tái)線程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

redo log 不可用時(shí)，將臟頁刷新到磁盤

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

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

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

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

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

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

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

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

舉個(gè)例子來具體解釋下：一組 4 個(gè)文件，每個(gè)文件的大小是 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 滿了，這時(shí)候不能再執(zhí)行新的更新，得停下來先覆蓋（擦掉）一些 redo log，把 CheckPoint 推進(jìn)一下。

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

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

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

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

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

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

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

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

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

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

編輯：jq