應用系統分層架構，為了加速資料訪問，會把最常訪問的資料，放在快取(cache)裡，避免每次都去訪問資料庫。

作業系統，會有緩衝池(buffer pool)機制，避免每次訪問磁碟，以加速資料的訪問。

MySQL作為一個儲存系統，同樣具有緩衝池(buffer pool)機制，以避免每次查詢資料都進行磁碟IO。

今天，和大家聊一聊InnoDB的緩衝池。

InnoDB的緩衝池快取什麼？有什麼用？

快取表資料與索引資料，把磁碟上的資料載入到緩衝池，避免每次訪問都進行磁碟IO，起到加速訪問的作用。

速度快，那為啥不把所有資料都放到緩衝池裡？

凡事都具備兩面性，拋開資料易失性不說，訪問快速的反面是儲存容量小：

（1）快取訪問快，但容量小，資料庫儲存了200G資料，快取容量可能只有64G；

（2）記憶體訪問快，但容量小，買一臺筆記本磁碟有2T，記憶體可能只有16G；

因此，只能把“最熱”的資料放到“最近”的地方，以“最大限度”的降低磁碟訪問。

如何管理與淘汰緩衝池，使得效能最大化呢？

在介紹具體細節之前，先介紹下“預讀”的概念。

什麼是預讀？

磁碟讀寫，並不是按需讀取，而是按頁讀取，一次至少讀一頁資料（一般是4K），如果未來要讀取的資料就在頁中，就能夠省去後續的磁碟IO，提高效率。

預讀為什麼有效？

資料訪問，通常都遵循“集中讀寫”的原則，使用一些資料，大概率會使用附近的資料，這就是所謂的“區域性性原理”，它表明提前載入是有效的，確實能夠減少磁碟IO。

按頁(4K)讀取，和InnoDB的緩衝池設計有啥關係？

（1）磁碟訪問按頁讀取能夠提高效能，所以緩衝池一般也是按頁快取資料；

（2）預讀機制啟示了我們，能把一些“可能要訪問”的頁提前加入緩衝池，避免未來的磁碟IO操作；

InnoDB是以什麼演算法，來管理這些緩衝頁呢？

最容易想到的，就是LRU(Least recently used)。

畫外音：memcache，OS都會用LRU來進行頁置換管理，但MySQL的玩法並不一樣。

傳統的LRU是如何進行緩衝頁管理？

最常見的玩法是，把入緩衝池的頁放到LRU的頭部，作為最近訪問的元素，從而最晚被淘汰。這裡又分兩種情況：

（1）頁已經在緩衝池裡

（2）頁不在緩衝池裡，除了做“放入”LRU頭部的動作，還要做“淘汰”LRU尾部頁的動作；

如上圖，假如管理緩衝池的LRU長度為10，緩衝了頁號為1，3，5…，40，7的頁。

假如，接下來要訪問的資料在頁號為4的頁中：

（1）頁號為4的頁，本來就在緩衝池裡；

（2）把頁號為4的頁，放到LRU的頭部即可，沒有頁被淘汰；

畫外音：為了減少資料移動，LRU一般用連結串列實現。

假如，再接下來要訪問的資料在頁號為50的頁中：

（1）頁號為50的頁，原來不在緩衝池裡；

（2）把頁號為50的頁，放到LRU頭部，同時淘汰尾部頁號為7的頁；

傳統的LRU緩衝池演算法十分直觀，OS，memcache等很多軟體都在用，MySQL為啥這麼矯情，不能直接用呢？

這裡有兩個問題：

（1）預讀失效；

（2）緩衝池汙染；

什麼是預讀失效？

由於預讀(Read-Ahead)，提前把頁放入了緩衝池，但最終MySQL並沒有從頁中讀取資料，稱為預讀失效。

如何對預讀失效進行優化？

要優化預讀失效，思路是：

（1）讓預讀失敗的頁，停留在緩衝池LRU裡的時間儘可能短；

（2）讓真正被讀取的頁，才挪到緩衝池LRU的頭部；

以保證，真正被讀取的熱資料留在緩衝池裡的時間儘可能長。

具體方法是：

（1）將LRU分為兩個部分：

• 新生代(new sublist)

• 老生代(old sublist)

（2）新老生代收尾相連，即：新生代的尾(tail)連線著老生代的頭(head)；

（3）新頁（例如被預讀的頁）加入緩衝池時，只加入到老生代頭部：

• 如果資料真正被讀取（預讀成功），才會加入到新生代的頭部

• 如果資料沒有被讀取，則會比新生代裡的“熱資料頁”更早被淘汰出緩衝池

舉個例子，整個緩衝池LRU如上圖：

（1）整個LRU長度是10；

（2）前70%是新生代；

（3）後30%是老生代；

（4）新老生代首尾相連；

假如有一個頁號為50的新頁被預讀加入緩衝池：

（1）50只會從老生代頭部插入，老生代尾部（也是整體尾部）的頁會被淘汰掉；

（2）假設50這一頁不會被真正讀取，即預讀失敗，它將比新生代的資料更早淘汰出緩衝池；

假如50這一頁立刻被讀取到，例如SQL訪問了頁內的行row資料：

（1）它會被立刻加入到新生代的頭部；

（2）新生代的頁會被擠到老生代，此時並不會有頁面被真正淘汰；

改進版緩衝池LRU能夠很好的解決“預讀失敗”的問題。

畫外音：但也不要因噎廢食，因為害怕預讀失敗而取消預讀策略，大部分情況下，區域性性原理是成立的，預讀是有效的。

新老生代改進版LRU仍然解決不了緩衝池汙染的問題。

什麼是MySQL緩衝池汙染？

當某一個SQL語句，要批量掃描大量資料時，可能導致把緩衝池的所有頁都替換出去，導致大量熱資料被換出，MySQL效能急劇下降，這種情況叫緩衝池汙染。

例如，有一個數據量較大的使用者表，當執行：

select * from user where name like "%shenjian%";

雖然結果集可能只有少量資料，但這類like不能命中索引，必須全表掃描，就需要訪問大量的頁：

（1）把頁加到緩衝池（插入老生代頭部）；

（2）從頁裡讀出相關的row（插入新生代頭部）；

（3）row裡的name欄位和字串shenjian進行比較，如果符合條件，加入到結果集中；

（4）…直到掃描完所有頁中的所有row…

如此一來，所有的資料頁都會被載入到新生代的頭部，但只會訪問一次，真正的熱資料被大量換出。

怎麼這類掃碼大量資料導致的緩衝池汙染問題呢？

MySQL緩衝池加入了一個“老生代停留時間視窗”的機制：

（1）假設T=老生代停留時間視窗；

（2）插入老生代頭部的頁，即使立刻被訪問，並不會立刻放入新生代頭部；

（3）只有滿足“被訪問”並且“在老生代停留時間”大於T，才會被放入新生代頭部；

繼續舉例，假如批量資料掃描，有51，52，53，54，55等五個頁面將要依次被訪問。

如果沒有“老生代停留時間視窗”的策略，這些批量被訪問的頁面，會換出大量熱資料。

加入“老生代停留時間視窗”策略後，短時間內被大量載入的頁，並不會立刻插入新生代頭部，而是優先淘汰那些，短期內僅僅訪問了一次的頁。

而只有在老生代呆的時間足夠久，停留時間大於T，才會被插入新生代頭部。

上述原理，對應InnoDB裡哪些引數？

有三個比較重要的引數。

引數：innodb_buffer_pool_size

介紹：配置緩衝池的大小，在記憶體允許的情況下，DBA往往會建議調大這個引數，越多資料和索引放到記憶體裡，資料庫的效能會越好。

引數：innodb_old_blocks_pct

介紹：老生代佔整個LRU鏈長度的比例，預設是37，即整個LRU中新生代與老生代長度比例是63:37。

畫外音：如果把這個引數設為100，就退化為普通LRU了。

引數：innodb_old_blocks_time

介紹：老生代停留時間視窗，單位是毫秒，預設是1000，即同時滿足“被訪問”與“在老生代停留時間超過1秒”兩個條件，才會被插入到新生代頭部。

總結

（1）緩衝池(buffer pool)是一種常見的降低磁碟訪問的機制；

（2）緩衝池通常以頁(page)為單位快取資料；

（3）緩衝池的常見管理演算法是LRU，memcache，OS，InnoDB都使用了這種演算法；

（4）InnoDB對普通LRU進行了優化：

• 將緩衝池分為老生代和新生代，入緩衝池的頁，優先進入老生代，頁被訪問，才進入新生代，以解決預讀失效的問題

• 頁被訪問，且在老生代停留時間超過配置閾值的，才進入新生代，以解決批量資料訪問，大量熱資料淘汰的問題

思路，比結論重要。

解決了什麼問題，比方案重要。