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

為什么要有 Buffer Pool?

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

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

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

有了緩沖池后：

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

Buffer Pool 有多大?

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

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

Buffer Pool 緩存什么?

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

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

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

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

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

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

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

為什么會有碎片空間呢?

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

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

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

不是的。

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

如何管理 Buffer Pool?

如何管理空閑頁?

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

但是此時并沒有真正的磁盤頁被緩存到 Buffer Pool 中，之后隨著程序的運行，會不斷的有磁盤上的頁被緩存到 Buffer Pool 中。

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

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

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

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

如何管理臟頁?

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

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

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

如何提高緩存命中率?

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

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

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

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

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

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

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

如果訪問了 3 號的頁，因為 3 號頁在 Buffer Pool 里，所以把 3 號頁移動到頭部即可。

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

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

圖中：

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

簡單的 LRU 算法并沒有被 MySQL 使用，因為簡單的 LRU 算法無法避免下面這兩個問題：

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

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

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

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

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

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

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

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

我們不能因為害怕預(yù)讀失效，而將預(yù)讀機制去掉，大部分情況下，局部性原理還是成立的。

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

那到底怎么才能避免呢?

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

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

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

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

接下來，給大家舉個例子。

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

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

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

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

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

什么是 Buffer Pool 污染?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這個間隔時間是由 innodb_old_blocks_time 控制的，默認是 1000 ms。

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

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

臟頁什么時候會被刷入磁盤?

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

• 將 LRU 鏈表 分為young 和 old 兩個區(qū)域，加入緩沖池的頁，優(yōu)先插入 old 區(qū)域;頁被訪問時，才進入 young 區(qū)域，目的是為了解決預(yù)讀失效的問題。
• 當「頁被訪問」且「 old 區(qū)域停留時間超過 innodb_old_blocks_time 閾值(默認為1秒)」時，才會將頁插入到 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)「偶爾」會出現(xiàn)一些用時稍長的 SQL，這可因為臟頁在刷新到磁盤時導(dǎo)致數(shù)據(jù)庫性能抖動。如果在較短的時間頻繁出現(xiàn)這種現(xiàn)象，就需要調(diào)大 Buffer Pool 空間或 redo log 日志的大小，從而減少臟頁刷入磁盤的頻率。