應用系統分層架構，為了加速資料通路，會把最常通路的資料，放在緩存(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）頁已經在緩沖池裡，那就隻做“移至”LRU頭部的動作，而沒有頁被淘汰；
（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進行了優化：
将緩沖池分為老生代和新生代，入緩沖池的頁，優先進入老生代，頁被通路，才進入新生代，以解決預讀失效的問題
頁被通路，且在老生代停留時間超過配置門檻值的，才進入新生代，以解決批量資料通路，大量熱資料淘汰的問題
思路，比結論重要。
解決了什麼問題，比方案重要。
本文轉自“架構師之路”公衆号，58沈劍提供。