[[384326]]

本文轉(zhuǎn)載自微信公眾號「程序員小飯」，作者飯米粒 。轉(zhuǎn)載本文請聯(lián)系程序員小飯公眾號。飯米粒  

前言

buffer pool是什么

咱們在使用mysql的時候，比如很簡單的select * from table;這條語句，具體查詢數(shù)據(jù)其實是在存儲引擎中實現(xiàn)的，大家都知道m(xù)ysql數(shù)據(jù)其實是放在磁盤里面的，如果每次查詢都直接從磁盤里面查詢，這樣勢必會很影響性能，所以一定是先把數(shù)據(jù)從磁盤中取出，然后放在內(nèi)存中，下次查詢直接從內(nèi)存中來取。但是一臺機器中往往不是只有mysql一個進程在運行的，很多個進程都需要使用內(nèi)存，所以mysql中會有一個專門的區(qū)域來處理這些數(shù)據(jù)，這個專門為mysql準備的區(qū)域，就叫buffer pool。

buffer pool的工作流程

咱們以查詢語句為例 1:在查詢的時候會先去buffer pool(內(nèi)存)中看看有沒有對應(yīng)的數(shù)據(jù)頁，如果有的話直接返回 2:如果buffer pool中沒有對應(yīng)的數(shù)據(jù)頁，則會去磁盤中查找，磁盤中如果找到了對應(yīng)的數(shù)據(jù)，則會把該頁的數(shù)據(jù)直接copy一份到buffer pool中返回給客戶端 3:下次有同樣的查詢進來直接查找buffer pool找到對應(yīng)的數(shù)據(jù)返回即可。

大家看到這里相信應(yīng)該對buffer pool有了個大概的認識，有沒有感覺有點緩存的感覺，當然buffer pool可沒有緩存那么簡單，內(nèi)部結(jié)構(gòu)還是比較復(fù)雜的，不過沒關(guān)系，咱們繼續(xù)往下看。

buffer pool數(shù)據(jù)管理

數(shù)據(jù)管理的基本單位

buffer pool畢竟是一種內(nèi)存管理，數(shù)據(jù)當然不是按照一條一條的sql語句來管理的，而是按照數(shù)據(jù)頁來管理的,innodb 引擎默認的數(shù)據(jù)頁是16kb，而buffer pool啟動的時候是默認的128M，所以是有8192個數(shù)據(jù)頁的。而磁盤的數(shù)據(jù)管理也是用數(shù)據(jù)頁為單位來管理的，所以每次查找數(shù)據(jù)的時候，先請求buffer pool，buffer pool中沒有的話會到磁盤中找到對應(yīng)的數(shù)據(jù)頁，然后copy到buffer pool中給客戶端返回。

free鏈表

正常情況下，buffer pool肯定是從第一個數(shù)據(jù)頁，不斷的往后填充的，一個一個的往后寫入,每次直接在后面追加就可以了。如下圖(黃色部分表示已經(jīng)寫入數(shù)據(jù))

但是實際生產(chǎn)環(huán)境中，并不是這樣的，我們不光有查詢操作，還有刪除，修改等操作，而且已經(jīng)寫入buffer pool的數(shù)據(jù)不一定是始終有價值的，有一些數(shù)據(jù)是不需要的，需要釋放對應(yīng)的數(shù)據(jù)頁的，所以就會造成buffer pool的數(shù)據(jù)其實是這種情況，間斷不連續(xù)的。

在這種情況下該如何去找到有效的空閑的數(shù)據(jù)頁空間來存儲數(shù)據(jù)呢?最直觀的方法就是從第一個頁遍歷的一個一個的往后找，找到空閑的數(shù)據(jù)頁即可，這種方法倒是可行，但是非常影響效率，所以mysql在處理這種問題用上了free鏈表的方式來管理空閑的數(shù)據(jù)頁。

大家可以看一看free鏈表的結(jié)構(gòu)

• free鏈表有一個基節(jié)點，記錄了該free鏈表的唯一標志，該鏈表的尾節(jié)點地址，以及鏈表的總長度
• 基節(jié)點后面會有很多的控制塊，控制塊本身很小，只是存儲了指向空閑數(shù)據(jù)頁的指針而已，所以buffer pool在尋找空閑數(shù)據(jù)頁的時候直接用free鏈表可以直接找到。
• 只要有一頁數(shù)據(jù)空閑出來之后，直接把該數(shù)據(jù)頁的地址追加到free鏈表即可。

flush鏈表

當然只是用free鏈表是解決不了所有問題的，比如：我們在執(zhí)行update table test set field_a = 1;的時候，我們是先修改buffer pool里面對應(yīng)的數(shù)據(jù)頁，然后再更新磁盤中對應(yīng)的數(shù)據(jù)頁的，(當然這里會涉及到一個數(shù)據(jù)一致性的問題，mysql是用redo log解決的，這個不在咱們這篇文章的討論范圍之內(nèi))我們把buffer pool中對應(yīng)修改的數(shù)據(jù)頁同步修改到磁盤的時候，這個過程稱之為"刷臟",刷臟是有一定策略的，可以用

select @@innodb_flush_log_at_trx_commit; 

來查看刷臟策略

我們一般都不會設(shè)置實時寫，這樣很影響性能，所以一般都是延遲寫的，那么就會引發(fā)一個問題，mysql是如何在buffer pool中找到被修改過的臟數(shù)據(jù)的呢?這里咱們就用上了flush鏈表了，其實和free鏈表比較像

flush鏈表上面維護的都是臟數(shù)據(jù)頁的指針。刷臟的時候直接遍歷flush鏈表去刷臟就可以了。

lru鏈表

buffer pool是有一定空間限制的，默認是128M，總會有空間塞滿的時候的，所以數(shù)據(jù)頁是有淘汰機制的，淘汰機制就是lru(最近最少使用)。

lru原理其實也很簡單，使用到過的數(shù)據(jù)頁，直接移動到鏈表的頭部，然后在buffer pool滿了之后直接淘汰掉鏈表尾部的數(shù)據(jù)頁就可以了。

lru鏈表的優(yōu)化

其實簡單的lru鏈表是存在一定的問題的，比如咱們在工作過程中，可能會用上 select * from test這樣的語句來進行一些刷數(shù)據(jù)等需求，如果test表是非常大的，很有可能一下子把buffer pool占滿，把之前的數(shù)據(jù)頁全部都淘汰掉，然后其余的數(shù)據(jù)在線上業(yè)務(wù)正常執(zhí)行的時候，又會回來重新把之前select * from test 占用的數(shù)據(jù)頁重新慢慢淘汰掉，這一來一去是非常影響線上的性能的。

所以鑒于以上所在的問題，mysql的buffer pool是在lru的基礎(chǔ)上進行了一些優(yōu)化的。

buffer pool的lru鏈表把數(shù)據(jù)分為了熱數(shù)據(jù)塊和冷數(shù)據(jù)塊，比例大概5:3的樣子，每次新的數(shù)據(jù)頁寫入都會寫入冷數(shù)據(jù)區(qū)。

但是如果這樣的話那么熱數(shù)據(jù)區(qū)永遠都不會有數(shù)據(jù)，所以冷數(shù)據(jù)區(qū)寫入的時候會另外記錄上寫入的時間，下次訪問該數(shù)據(jù)區(qū)的時候如果時間間隔大于1s,那么就會放入熱數(shù)據(jù)區(qū)，這樣就不會淘汰掉大量的無辜數(shù)據(jù)。所以我們在執(zhí)行select * from test這種語句刷新腳本的時候，只會占用冷數(shù)據(jù)的空間，而不會影響到熱數(shù)據(jù)。