今天聊 MySQL 的 Buffer Pool，發(fā)車!

為什么要有 Buffer Pool?

雖然說 MySQL 的數(shù)據(jù)是存儲(chǔ)在磁盤里的，但是也不能每次都從磁盤里面讀取數(shù)據(jù)，這樣性能是極差的。

要想提升查詢性能，加個(gè)緩存就行了嘛。所以，當(dāng)數(shù)據(jù)從磁盤中取出后，緩存內(nèi)存中，下次查詢同樣的數(shù)據(jù)的時(shí)候，直接從內(nèi)存中讀取。

為此，Innodb 存儲(chǔ)引擎設(shè)計(jì)了一個(gè)緩沖池(Buffer Pool)，來提高數(shù)據(jù)庫的讀寫性能。

有了緩沖池后：

• 當(dāng)讀取數(shù)據(jù)時(shí)，如果數(shù)據(jù)存在于 Buffer Pool 中，客戶端就會(huì)直接讀取 Buffer Pool 中的數(shù)據(jù)，否則再去磁盤中讀取。
• 當(dāng)修改數(shù)據(jù)時(shí)，首先是修改 Buffer Pool 中數(shù)據(jù)所在的頁，然后將其頁設(shè)置為臟頁，最后由后臺(tái)線程將臟頁寫入到磁盤。

Buffer Pool 有多大?

Buffer Pool 是在 MySQL 啟動(dòng)的時(shí)候，向操作系統(tǒng)申請(qǐng)的一片連續(xù)的內(nèi)存空間，默認(rèn)配置下 Buffer Pool 只有 128MB 。

可以通過調(diào)整 innodb_buffer_pool_size 參數(shù)來設(shè)置 Buffer Pool 的大小，一般建議設(shè)置成可用物理內(nèi)存的 60%~80%。

Buffer Pool 緩存什么?

InnoDB 會(huì)把存儲(chǔ)的數(shù)據(jù)劃分為若干個(gè)「頁」，以頁作為磁盤和內(nèi)存交互的基本單位，一個(gè)頁的默認(rèn)大小為 16KB。因此，Buffer Pool 同樣需要按「頁」來劃分。

在 MySQL 啟動(dòng)的時(shí)候，InnoDB 會(huì)為 Buffer Pool 申請(qǐng)一片連續(xù)的內(nèi)存空間，然后按照默認(rèn)的16KB的大小劃分出一個(gè)個(gè)的頁， Buffer Pool 中的頁就叫做緩存頁。此時(shí)這些緩存頁都是空閑的，之后隨著程序的運(yùn)行，才會(huì)有磁盤上的頁被緩存到 Buffer Pool 中。

所以，MySQL 剛啟動(dòng)的時(shí)候，你會(huì)觀察到使用的虛擬內(nèi)存空間很大，而使用到的物理內(nèi)存空間卻很小，這是因?yàn)橹挥羞@些虛擬內(nèi)存被訪問后，操作系統(tǒng)才會(huì)觸發(fā)缺頁中斷，接著將虛擬地址和物理地址建立映射關(guān)系。

Buffer Pool 除了緩存「索引頁」和「數(shù)據(jù)頁」，還包括了 undo 頁，插入緩存、自適應(yīng)哈希索引、鎖信息等等。

為了更好的管理這些在 Buffer Pool 中的緩存頁，InnoDB 為每一個(gè)緩存頁都創(chuàng)建了一個(gè)控制塊，控制塊信息包括「緩存頁的表空間、頁號(hào)、緩存頁地址、鏈表節(jié)點(diǎn)」等等。

控制塊也是占有內(nèi)存空間的，它是放在 Buffer Pool 的最前面，接著才是緩存頁，如下圖：

上圖中控制塊和緩存頁之間灰色部分稱為碎片空間。

為什么會(huì)有碎片空間呢?

你想想啊，每一個(gè)控制塊都對(duì)應(yīng)一個(gè)緩存頁，那在分配足夠多的控制塊和緩存頁后，可能剩余的那點(diǎn)兒空間不夠一對(duì)控制塊和緩存頁的大小，自然就用不到嘍，這個(gè)用不到的那點(diǎn)兒內(nèi)存空間就被稱為碎片了。

當(dāng)然，如果你把 Buffer Pool 的大小設(shè)置的剛剛好的話，也可能不會(huì)產(chǎn)生碎片。

查詢一條記錄，就只需要緩沖一條記錄嗎?

不是的。

當(dāng)我們查詢一條記錄時(shí)，InnoDB 是會(huì)把整個(gè)頁的數(shù)據(jù)加載到 Buffer Pool 中，因?yàn)?，通過索引只能定位到磁盤中的頁，而不能定位到頁中的一條記錄。將頁加載到 Buffer Pool 后，再通過頁里的頁目錄去定位到某條具體的記錄。

如何管理 Buffer Pool?

如何管理空閑頁?

當(dāng)啟動(dòng) Mysql 服務(wù)器的時(shí)候，需要完成對(duì) Buffer Pool 的初始化過程，即分配 Buffer Pool 的內(nèi)存空間，把它劃分為若干對(duì)控制塊和緩存頁。

但是此時(shí)并沒有真正的磁盤頁被緩存到 Buffer Pool 中，之后隨著程序的運(yùn)行，會(huì)不斷的有磁盤上的頁被緩存到 Buffer Pool 中。

為了標(biāo)記哪些頁是空閑頁，就使用了鏈表結(jié)構(gòu)，將空閑緩存頁的「控制塊」作為鏈表的節(jié)點(diǎn)，一個(gè)一個(gè)串起來，這個(gè)鏈表稱為 Free 鏈表(空閑鏈表)。

Free 鏈表上除了有控制塊，還有一個(gè)頭節(jié)點(diǎn)，該頭節(jié)點(diǎn)包含鏈表的頭節(jié)點(diǎn)地址，尾節(jié)點(diǎn)地址，以及當(dāng)前鏈表中節(jié)點(diǎn)的數(shù)量等信息。

Free 鏈表節(jié)點(diǎn)是一個(gè)一個(gè)的控制塊，而每個(gè)控制塊包含著對(duì)應(yīng)緩存頁的地址，所以相當(dāng)于 Free 鏈表節(jié)點(diǎn)都對(duì)應(yīng)一個(gè)空閑的緩存頁。

有了 Free 鏈表后，每當(dāng)需要從磁盤中加載一個(gè)頁到 Buffer Pool 中時(shí)，就從 Free 鏈表中取一個(gè)空閑的緩存頁，并且把該緩存頁對(duì)應(yīng)的控制塊的信息填上，然后把該緩存頁對(duì)應(yīng)的控制塊從 Free 鏈表中移除。

如何管理臟頁?

設(shè)計(jì) Buffer Pool 除了能提高讀性能，還能提高寫性能，也就是更新數(shù)據(jù)的時(shí)候，不需要每次都要寫入磁盤，而是將 Buffer Pool 對(duì)應(yīng)的緩存頁標(biāo)記為臟頁，然后再由后臺(tái)線程將臟頁寫入到磁盤。

那為了能快速知道哪些緩存頁是臟的，于是就設(shè)計(jì)出 Flush 鏈表，它跟 Free 鏈表類似的，鏈表的節(jié)點(diǎn)也是控制塊，區(qū)別在于 Flush 鏈表的元素都是臟頁。

有了 Flush 鏈表后，后臺(tái)線程就可以遍歷 Flush 鏈表，將臟頁寫入到磁盤。

如何提高緩存命中率?

Buffer Pool 的大小是有限的，對(duì)于一些頻繁訪問的數(shù)據(jù)我們希望可以一直留在 Buffer Pool 中，而一些很少訪問的數(shù)據(jù)希望可以在某些時(shí)機(jī)可以淘汰掉，從而保證 Buffer Pool 不會(huì)因?yàn)闈M了而導(dǎo)致無法再緩存新的數(shù)據(jù)，同時(shí)還能保證常用數(shù)據(jù)留在 Buffer Pool 中。

要實(shí)現(xiàn)這個(gè)，最容易想到的就是 LRU(Least recently used)算法。

該算法的思路是，鏈表頭部的節(jié)點(diǎn)是最近使用的，而鏈表末尾的節(jié)點(diǎn)是最久沒被使用的。那么，當(dāng)空間不夠了，就淘汰最久沒被使用的節(jié)點(diǎn)，從而騰出空間。

簡單的 LRU 算法的實(shí)現(xiàn)思路是這樣的：

當(dāng)訪問的頁在 Buffer Pool 里，就直接把該頁對(duì)應(yīng)的 LRU 鏈表節(jié)點(diǎn)移動(dòng)到鏈表的頭部。

當(dāng)訪問的頁不在 Buffer Pool 里，除了要把頁放入到 LRU 鏈表的頭部，還要淘汰 LRU 鏈表末尾的節(jié)點(diǎn)。

比如下圖，假設(shè) LRU 鏈表長度為 5，LRU 鏈表從左到右有 1，2，3，4，5 的頁。

如果訪問了 3 號(hào)的頁，因?yàn)?3 號(hào)頁在 Buffer Pool 里，所以把 3 號(hào)頁移動(dòng)到頭部即可。

而如果接下來，訪問了 8 號(hào)頁，因?yàn)?8 號(hào)頁不在 Buffer Pool 里，所以需要先淘汰末尾的 5 號(hào)頁，然后再將 8 號(hào)頁加入到頭部。

到這里我們可以知道，Buffer Pool 里有三種頁和鏈表來管理數(shù)據(jù)。

圖中：

• Free Page(空閑頁)，表示此頁未被使用，位于 Free 鏈表;
• Clean Page(干凈頁)，表示此頁已被使用，但是頁面未發(fā)生修改，位于LRU 鏈表。
• Dirty Page(臟頁)，表示此頁「已被使用」且「已經(jīng)被修改」，其數(shù)據(jù)和磁盤上的數(shù)據(jù)已經(jīng)不一致。當(dāng)臟頁上的數(shù)據(jù)寫入磁盤后，內(nèi)存數(shù)據(jù)和磁盤數(shù)據(jù)一致，那么該頁就變成了干凈頁。臟頁同時(shí)存在于 LRU 鏈表和 Flush 鏈表。

簡單的 LRU 算法并沒有被 MySQL 使用，因?yàn)楹唵蔚?LRU 算法無法避免下面這兩個(gè)問題：

• 預(yù)讀失效;
• Buffer Pool 污染;

什么是預(yù)讀失效?

先來說說 MySQL 的預(yù)讀機(jī)制。程序是有空間局部性的，靠近當(dāng)前被訪問數(shù)據(jù)的數(shù)據(jù)，在未來很大概率會(huì)被訪問到。

所以，MySQL 在加載數(shù)據(jù)頁時(shí)，會(huì)提前把它相鄰的數(shù)據(jù)頁一并加載進(jìn)來，目的是為了減少磁盤 IO。

但是可能這些被提前加載進(jìn)來的數(shù)據(jù)頁，并沒有被訪問，相當(dāng)于這個(gè)預(yù)讀是白做了，這個(gè)就是預(yù)讀失效。

如果使用簡單的 LRU 算法，就會(huì)把預(yù)讀頁放到 LRU 鏈表頭部，而當(dāng) Buffer Pool空間不夠的時(shí)候，還需要把末尾的頁淘汰掉。

如果這些預(yù)讀頁如果一直不會(huì)被訪問到，就會(huì)出現(xiàn)一個(gè)很奇怪的問題，不會(huì)被訪問的預(yù)讀頁卻占用了 LRU 鏈表前排的位置，而末尾淘汰的頁，可能是頻繁訪問的頁，這樣就大大降低了緩存命中率。

怎么解決預(yù)讀失效而導(dǎo)致緩存命中率降低的問題?

我們不能因?yàn)楹ε骂A(yù)讀失效，而將預(yù)讀機(jī)制去掉，大部分情況下，局部性原理還是成立的。

要避免預(yù)讀失效帶來影響，最好就是讓預(yù)讀的頁停留在 Buffer Pool 里的時(shí)間要盡可能的短，讓真正被訪問的頁才移動(dòng)到 LRU 鏈表的頭部，從而保證真正被讀取的熱數(shù)據(jù)留在 Buffer Pool 里的時(shí)間盡可能長。

那到底怎么才能避免呢?

MySQL 是這樣做的，它改進(jìn)了 LRU 算法，將 LRU 劃分了 2 個(gè)區(qū)域：old 區(qū)域 和 young 區(qū)域。

young 區(qū)域在 LRU 鏈表的前半部分，old 區(qū)域則是在后半部分，如下圖：

old 區(qū)域占整個(gè) LRU 鏈表長度的比例可以通過 innodb_old_blocks_pc 參數(shù)來設(shè)置，默認(rèn)是 37，代表整個(gè) LRU 鏈表中 young 區(qū)域與 old 區(qū)域比例是 63:37。

劃分這兩個(gè)區(qū)域后，預(yù)讀的頁就只需要加入到 old 區(qū)域的頭部，當(dāng)頁被真正訪問的時(shí)候，才將頁插入 young 區(qū)域的頭部。如果預(yù)讀的頁一直沒有被訪問，就會(huì)從 old 區(qū)域移除，這樣就不會(huì)影響 young 區(qū)域中的熱點(diǎn)數(shù)據(jù)。

接下來，給大家舉個(gè)例子。

假設(shè)有一個(gè)長度為 10 的 LRU 鏈表，其中 young 區(qū)域占比 70 %，old 區(qū)域占比 20 %。

現(xiàn)在有個(gè)編號(hào)為 20 的頁被預(yù)讀了，這個(gè)頁只會(huì)被插入到 old 區(qū)域頭部，而 old 區(qū)域末尾的頁(10號(hào))會(huì)被淘汰掉。

如果 20 號(hào)頁一直不會(huì)被訪問，它也沒有占用到 young 區(qū)域的位置，而且還會(huì)比 young 區(qū)域的數(shù)據(jù)更早被淘汰出去。

如果 20 號(hào)頁被預(yù)讀后，立刻被訪問了，那么就會(huì)將它插入到 young 區(qū)域的頭部，young 區(qū)域末尾的頁(7號(hào))，會(huì)被擠到 old 區(qū)域，作為 old 區(qū)域的頭部，這個(gè)過程并不會(huì)有頁被淘汰。

雖然通過劃分 old 區(qū)域 和 young 區(qū)域避免了預(yù)讀失效帶來的影響，但是還有個(gè)問題無法解決，那就是 Buffer Pool 污染的問題。

什么是 Buffer Pool 污染?

當(dāng)某一個(gè) SQL 語句掃描了大量的數(shù)據(jù)時(shí)，在 Buffer Pool 空間比較有限的情況下，可能會(huì)將 Buffer Pool 里的所有頁都替換出去，導(dǎo)致大量熱數(shù)據(jù)被淘汰了，等這些熱數(shù)據(jù)又被再次訪問的時(shí)候，由于緩存未命中，就會(huì)產(chǎn)生大量的磁盤 IO，MySQL 性能就會(huì)急劇下降，這個(gè)過程被稱為 Buffer Pool 污染。

注意， Buffer Pool 污染并不只是查詢語句查詢出了大量的數(shù)據(jù)才出現(xiàn)的問題，即使查詢出來的結(jié)果集很小，也會(huì)造成 Buffer Pool 污染。

比如，在一個(gè)數(shù)據(jù)量非常大的表，執(zhí)行了這條語句：

select * from t_user where name like "%xiaolin%";

可能這個(gè)查詢出來的結(jié)果就幾條記錄，但是由于這條語句會(huì)發(fā)生索引失效，所以這個(gè)查詢過程是全表掃描的，接著會(huì)發(fā)生如下的過程：

• 從磁盤讀到的頁加入到 LRU 鏈表的 old 區(qū)域頭部;
• 當(dāng)從頁里讀取行記錄時(shí)，也就是頁被訪問的時(shí)候，就要將該頁放到 young 區(qū)域頭部;
• 接下來拿行記錄的 name 字段和字符串 xiaolin 進(jìn)行模糊匹配，如果符合條件，就加入到結(jié)果集里;
• 如此往復(fù)，直到掃描完表中的所有記錄。

經(jīng)過這一番折騰，原本 young 區(qū)域的熱點(diǎn)數(shù)據(jù)都會(huì)被替換掉。

舉個(gè)例子，假設(shè)需要批量掃描：21，22，23，24，25 這五個(gè)頁，這些頁都會(huì)被逐一訪問(讀取頁里的記錄)。

在批量訪問這些數(shù)據(jù)的時(shí)候，會(huì)被逐一插入到 young 區(qū)域頭部。

可以看到，原本在 young 區(qū)域的熱點(diǎn)數(shù)據(jù) 6 和 7 號(hào)頁都被淘汰了，這就是 Buffer Pool 污染的問題。

怎么解決出現(xiàn) Buffer Pool 污染而導(dǎo)致緩存命中率下降的問題?

像前面這種全表掃描的查詢，很多緩沖頁其實(shí)只會(huì)被訪問一次，但是它卻只因?yàn)楸辉L問了一次而進(jìn)入到 young 區(qū)域，從而導(dǎo)致熱點(diǎn)數(shù)據(jù)被替換了。

LRU 鏈表中 young 區(qū)域就是熱點(diǎn)數(shù)據(jù)，只要我們提高進(jìn)入到 young 區(qū)域的門檻，就能有效地保證 young 區(qū)域里的熱點(diǎn)數(shù)據(jù)不會(huì)被替換掉。

MySQL 是這樣做的，進(jìn)入到 young 區(qū)域條件增加了一個(gè)停留在 old 區(qū)域的時(shí)間判斷。

具體是這樣做的，在對(duì)某個(gè)處在 old 區(qū)域的緩存頁進(jìn)行第一次訪問時(shí)，就在它對(duì)應(yīng)的控制塊中記錄下來這個(gè)訪問時(shí)間：

• 如果后續(xù)的訪問時(shí)間與第一次訪問的時(shí)間在某個(gè)時(shí)間間隔內(nèi)，那么該緩存頁就不會(huì)被從 old 區(qū)域移動(dòng)到 young 區(qū)域的頭部;
• 如果后續(xù)的訪問時(shí)間與第一次訪問的時(shí)間不在某個(gè)時(shí)間間隔內(nèi)，那么該緩存頁移動(dòng)到 young 區(qū)域的頭部;

這個(gè)間隔時(shí)間是由 innodb_old_blocks_time 控制的，默認(rèn)是 1000 ms。

也就說，只有同時(shí)滿足「被訪問」與「在 old 區(qū)域停留時(shí)間超過 1 秒」兩個(gè)條件，才會(huì)被插入到 young 區(qū)域頭部，這樣就解決了 Buffer Pool 污染的問題 。

另外，MySQL 針對(duì) young 區(qū)域其實(shí)做了一個(gè)優(yōu)化，為了防止 young 區(qū)域節(jié)點(diǎn)頻繁移動(dòng)到頭部。young 區(qū)域前面 1/4 被訪問不會(huì)移動(dòng)到鏈表頭部，只有后面的 3/4被訪問了才會(huì)。

臟頁什么時(shí)候會(huì)被刷入磁盤?

引入了 Buffer Pool 后，當(dāng)修改數(shù)據(jù)時(shí)，首先是修改 Buffer Pool 中數(shù)據(jù)所在的頁，然后將其頁設(shè)置為臟頁，但是磁盤中還是原數(shù)據(jù)。

因此，臟頁需要被刷入磁盤，保證緩存和磁盤數(shù)據(jù)一致，但是若每次修改數(shù)據(jù)都刷入磁盤，則性能會(huì)很差，因此一般都會(huì)在一定時(shí)機(jī)進(jìn)行批量刷盤。

可能大家擔(dān)心，如果在臟頁還沒有來得及刷入到磁盤時(shí)，MySQL 宕機(jī)了，不就丟失數(shù)據(jù)了嗎?

這個(gè)不用擔(dān)心，InnoDB 的更新操作采用的是 Write Ahead Log 策略，即先寫日志，再寫入磁盤，通過 redo log 日志讓 MySQL 擁有了崩潰恢復(fù)能力。

下面幾種情況會(huì)觸發(fā)臟頁的刷新：

• 當(dāng) redo log 日志滿了的情況下，會(huì)主動(dòng)觸發(fā)臟頁刷新到磁盤;
• Buffer Pool 空間不足時(shí)，需要將一部分?jǐn)?shù)據(jù)頁淘汰掉，如果淘汰的是臟頁，需要先將臟頁同步到磁盤;
• MySQL 認(rèn)為空閑時(shí)，后臺(tái)線程回定期將適量的臟頁刷入到磁盤;
• MySQL 正常關(guān)閉之前，會(huì)把所有的臟頁刷入到磁盤;

在我們開啟了慢 SQL 監(jiān)控后，如果你發(fā)現(xiàn)「偶爾」會(huì)出現(xiàn)一些用時(shí)稍長的 SQL，這可能是因?yàn)榕K頁在刷新到磁盤時(shí)可能會(huì)給數(shù)據(jù)庫帶來性能開銷，導(dǎo)致數(shù)據(jù)庫操作抖動(dòng)。

如果間斷出現(xiàn)這種現(xiàn)象，就需要調(diào)大 Buffer Pool 空間或 redo log 日志的大小。

總結(jié)

Innodb 存儲(chǔ)引擎設(shè)計(jì)了一個(gè)緩沖池(Buffer Pool)，來提高數(shù)據(jù)庫的讀寫性能。

Buffer Pool 以頁為單位緩沖數(shù)據(jù)，可以通過 innodb_buffer_pool_size 參數(shù)調(diào)整緩沖池的大小，默認(rèn)是 128 M。

Innodb 通過三種鏈表來管理緩頁：

• Free List (空閑頁鏈表)，管理空閑頁;
• Flush List (臟頁鏈表)，管理臟頁;
• LRU List，管理臟頁+干凈頁，將最近且經(jīng)常查詢的數(shù)據(jù)緩存在其中，而不常查詢的數(shù)據(jù)就淘汰出去。;

InnoDB 對(duì) LRU 做了一些優(yōu)化，我們熟悉的 LRU 算法通常是將最近查詢的數(shù)據(jù)放到 LRU 鏈表的頭部，而 InnoDB 做 2 點(diǎn)優(yōu)化：

• 將 LRU 鏈表 分為young 和 old 兩個(gè)區(qū)域，加入緩沖池的頁，優(yōu)先插入 old 區(qū)域;頁被訪問時(shí)，才進(jìn)入 young 區(qū)域，目的是為了解決預(yù)讀失效的問題。
• 當(dāng)「頁被訪問」且「 old 區(qū)域停留時(shí)間超過 innodb_old_blocks_time 閾值(默認(rèn)為1秒)」時(shí)，才會(huì)將頁插入到 young 區(qū)域，否則還是插入到 old 區(qū)域，目的是為了解決批量數(shù)據(jù)訪問，大量熱數(shù)據(jù)淘汰的問題。

可以通過調(diào)整 innodb_old_blocks_pc 參數(shù)，設(shè)置 young 區(qū)域和 old 區(qū)域比例。

在開啟了慢 SQL 監(jiān)控后，如果你發(fā)現(xiàn)「偶爾」會(huì)出現(xiàn)一些用時(shí)稍長的 SQL，這可因?yàn)榕K頁在刷新到磁盤時(shí)導(dǎo)致數(shù)據(jù)庫性能抖動(dòng)。如果在較短的時(shí)間頻繁出現(xiàn)這種現(xiàn)象，就需要調(diào)大 Buffer Pool 空間或 redo log 日志的大小，從而減少臟頁刷入磁盤的頻率。