[[384326]]

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

前言

buffer pool是什么

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

buffer pool的工作流程

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

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

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

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

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

free鏈表

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

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

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

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

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

flush鏈表

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

select @@innodb_flush_log_at_trx_commit; 

來查看刷臟策略

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

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

lru鏈表

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

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

lru鏈表的優(yōu)化

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

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

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

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