一、前言

1、buffer pool是什么

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

如下圖所示：

在對(duì)數(shù)據(jù)庫(kù)執(zhí)行增刪改操作的時(shí)候，不可能直接更新磁盤上的數(shù)據(jù)的，因?yàn)槿绻銓?duì)磁盤進(jìn)行隨機(jī)讀寫(xiě)操作，那速度是相當(dāng)?shù)穆?，隨便一個(gè)大磁盤文件的隨機(jī)讀寫(xiě)操作，可能都要幾百毫秒。如果要是那么搞的話，可能你的數(shù)據(jù)庫(kù)每秒也就只能處理幾百個(gè)請(qǐng)求了！ 在對(duì)數(shù)據(jù)庫(kù)執(zhí)行增刪改操作的時(shí)候，實(shí)際上主要都是針對(duì)內(nèi)存里的Buffer Pool中的數(shù)據(jù)進(jìn)行的，也就是實(shí)際上主要是對(duì)**數(shù)據(jù)庫(kù)的內(nèi)存(Buffer Pool)**里的數(shù)據(jù)結(jié)構(gòu)進(jìn)行了增刪改。
如下圖所示：

操作內(nèi)存的主要問(wèn)題就是在數(shù)據(jù)庫(kù)的內(nèi)存里執(zhí)行了一堆增刪改的操作，內(nèi)存數(shù)據(jù)是更新了，但是這個(gè)時(shí)候如果數(shù)據(jù)庫(kù)突然崩潰了，那么內(nèi)存里更新好的數(shù)據(jù)不是都沒(méi)了嗎？ MySQL就怕這個(gè)問(wèn)題，所以引入了一個(gè)redo log機(jī)制，你在對(duì)內(nèi)存里的數(shù)據(jù)進(jìn)行增刪改的時(shí)候，他同時(shí)會(huì)把增刪改對(duì)應(yīng)的日志寫(xiě)入redo log中。

如下圖：

萬(wàn)一數(shù)據(jù)庫(kù)突然崩潰了，沒(méi)關(guān)系，只要從redo log日志文件里讀取出來(lái)你之前做過(guò)哪些增刪改操作，瞬間就可以重新把這些增刪改操作在你的內(nèi)存里執(zhí)行一遍，這就可以恢復(fù)出來(lái)你之前做過(guò)哪些增刪改操作了。
當(dāng)然對(duì)于數(shù)據(jù)更新的過(guò)程，它是有一套嚴(yán)密的步驟的，還涉及到undo log、binlog、提交事務(wù)、buffer pool臟數(shù)據(jù)刷回磁盤等等。

小結(jié)：

Buffer Pool就是數(shù)據(jù)庫(kù)的一個(gè)內(nèi)存組件，里面緩存了磁盤上的真實(shí)數(shù)據(jù)，然后我們的系統(tǒng)對(duì)數(shù)據(jù)庫(kù)執(zhí)行的增刪改操作，其實(shí)主要就是對(duì)這個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)中的緩存數(shù)據(jù)執(zhí)行的。通過(guò)這種方式，保證每個(gè)更新請(qǐng)求，盡量就是只更新內(nèi)存，然后往磁盤順序?qū)懭罩疚募?br />更新內(nèi)存的性能是極高的，然后順序?qū)懘疟P上的日志文件的性能也是比較高的，因?yàn)轫樞驅(qū)懘疟P文件，他的性能要遠(yuǎn)高于隨機(jī)讀寫(xiě)磁盤文件。

2、buffer pool的工作流程

以查詢語(yǔ)句為例

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

3、buffer pool緩沖池和查詢緩存(query cache)

在正式講解buffer pool 之前，我們先搞清楚buffer pool緩沖池和查詢緩存(query cache)簡(jiǎn)稱Qcache的區(qū)別。

如果將Mysql分為Server層和存儲(chǔ)引擎層兩大部分，那么Qcache位于Server層，Buffer Pool位于存儲(chǔ)引擎層。

如果Mysql 查詢緩存功能是打開(kāi)的，那么當(dāng)一個(gè)sql進(jìn)入Mysql Server之后，Mysql Server首先會(huì)從查詢緩存中查看是否曾經(jīng)執(zhí)行過(guò)這個(gè)SQL，如果曾經(jīng)執(zhí)行過(guò)的話，曾經(jīng)執(zhí)行的查詢結(jié)果之前會(huì)以key-value的形式保存在查詢緩存中。key是sql語(yǔ)句，value是查詢結(jié)果。我們將這個(gè)過(guò)程稱為查詢緩存。查詢緩存會(huì)被所有的session共享。
如果查詢緩存中沒(méi)有你要找的數(shù)據(jù)的話，MySQL才會(huì)執(zhí)行后續(xù)的邏輯，通過(guò)存儲(chǔ)引擎將數(shù)據(jù)檢索出來(lái)。
MySQL查詢緩存是查詢結(jié)果緩存。它將以SEL開(kāi)頭的查詢與哈希表進(jìn)行比較，如果匹配，則返回上一次查詢的結(jié)果。進(jìn)行匹配時(shí)，查詢必須逐字節(jié)匹配，例如 SELECT * FROM t1; 不等于select * from t1;，此外，一些不確定的查詢結(jié)果無(wú)法被緩存，任何對(duì)表的修改都會(huì)導(dǎo)致這些表的所有緩存無(wú)效(只要有一個(gè)sql update了該表，那么表的查詢緩存就會(huì)失效)。因此，適用于查詢緩存的最理想的方案是只讀，特別是需要檢查數(shù)百萬(wàn)行后僅返回?cái)?shù)行的復(fù)雜查詢。如果你的查詢符合這樣一個(gè)特點(diǎn)，開(kāi)啟查詢緩存會(huì)提升你的查詢性能。
MySQL查詢緩存的目的是為了提升查詢性能，但它本身也是有性能開(kāi)銷的。需要在合適的業(yè)務(wù)場(chǎng)景下（讀寫(xiě)壓力模型）使用，不合適的業(yè)務(wù)場(chǎng)景不但不能提升查詢性能，查詢緩存反而會(huì)變成MySQL的瓶頸。

查詢緩存的開(kāi)銷主要有：

• 讀查詢?cè)陂_(kāi)始前必須先檢查是否命中緩存；
• 如果這個(gè)讀查詢可以被緩存，那么當(dāng)完成執(zhí)行后，MySQL若發(fā)現(xiàn)查詢緩存中沒(méi)有這個(gè)查詢，會(huì)將其結(jié)果存入查詢緩存，這會(huì)帶來(lái)額外的系統(tǒng)消耗；
• 當(dāng)向某個(gè)表寫(xiě)入數(shù)據(jù)的時(shí)候，MySQL必須將對(duì)應(yīng)表的所有緩存都設(shè)置失效。如果查詢緩存非常大或者碎片很多，這個(gè)操作就可能帶來(lái)很大的系統(tǒng)消耗。

查詢緩存的缺點(diǎn)：
首先，查詢緩存的效果取決于緩存的命中率，只有命中緩存的查詢效果才能有改善，因此無(wú)法預(yù)測(cè)其性能。只要有一個(gè)sql update了該表，那么表的查詢緩存就會(huì)失效，所以當(dāng)你的業(yè)務(wù)對(duì)表CRUD的比例不相上下，那么查詢緩存會(huì)影響應(yīng)用的吞吐效率。
其次，查詢緩存的另一個(gè)大問(wèn)題是它受到單個(gè)互斥鎖的保護(hù)。在具有多個(gè)內(nèi)核的服務(wù)器上，大量查詢會(huì)導(dǎo)致大量的互斥鎖爭(zhēng)用。

注意：在mysql8.0的版本中，已經(jīng)將查詢緩存模塊刪除了。

二、buffer pool的內(nèi)存數(shù)據(jù)結(jié)構(gòu)

1、數(shù)據(jù)頁(yè)概念

我們先了解一下數(shù)據(jù)頁(yè)這個(gè)概念。它是 MySQL 抽象出來(lái)的數(shù)據(jù)單位，磁盤文件中就是存放了很多數(shù)據(jù)頁(yè)，每個(gè)數(shù)據(jù)頁(yè)里存放了很多行數(shù)據(jù)。
默認(rèn)情況下，數(shù)據(jù)頁(yè)的大小是 16kb。
所以對(duì)應(yīng)的，在 Buffer Pool 中，也是以數(shù)據(jù)頁(yè)為數(shù)據(jù)單位，存放著很多數(shù)據(jù)。但是我們通常叫做緩存頁(yè)，因?yàn)?Buffer Pool 畢竟是一個(gè)緩沖池，并且里面的數(shù)據(jù)都是從磁盤文件中緩存到內(nèi)存中。它和磁盤文件中數(shù)據(jù)頁(yè)是一一對(duì)應(yīng)的。

假設(shè)我們要更新一行數(shù)據(jù)，此時(shí)數(shù)據(jù)庫(kù)會(huì)找到這行數(shù)據(jù)所在的數(shù)據(jù)頁(yè)，然后從磁盤文件里把這行數(shù)據(jù)所在的數(shù)據(jù)頁(yè)直接給加載到Buffer Pool里去。如下圖。

2、那么怎么識(shí)別數(shù)據(jù)在哪個(gè)緩存頁(yè)中

每個(gè)緩存頁(yè)都會(huì)對(duì)應(yīng)著一個(gè)描述數(shù)據(jù)塊，里面包含數(shù)據(jù)頁(yè)所屬的表空間、數(shù)據(jù)頁(yè)的編號(hào)，緩存頁(yè)在 Buffer Pool 中的地址等等。
描述數(shù)據(jù)塊本身也是一塊數(shù)據(jù)，它的大小大概是緩存頁(yè)大小的5%左右。假設(shè)你設(shè)置的buffer pool大小是128MB，實(shí)際上Buffer Pool真正的最終大小會(huì)超出一些，可能有個(gè)130多MB的樣子，因?yàn)樗锩孢€要存放每個(gè)緩存頁(yè)的描述數(shù)據(jù)。
在Buffer Pool中，每個(gè)緩存頁(yè)的描述數(shù)據(jù)放在最前面，然后各個(gè)緩存頁(yè)放在后面。

所以Buffer Pool實(shí)際看起來(lái)大概如下：

3、buffer pool的初始化與配置

3.1、初始化

• MySQL 啟動(dòng)時(shí)，會(huì)根據(jù)參數(shù) innodb_buffer_pool_size 的值來(lái)為 Buffer Pool 分配內(nèi)存區(qū)域。
• 然后會(huì)按照緩存頁(yè)的默認(rèn)大小 16k 以及對(duì)應(yīng)的描述數(shù)據(jù)塊大小，在 Buffer Pool 中劃分中一個(gè)個(gè)的緩存頁(yè)和一個(gè)個(gè)的描述數(shù)據(jù)庫(kù)塊。
• 注意：此時(shí)的緩存頁(yè)和描述數(shù)據(jù)塊都是空的，畢竟才剛啟動(dòng) MySQL。

3.2、buffer pool的配置

buffer pool通常由數(shù)個(gè)內(nèi)存塊加上一組控制結(jié)構(gòu)體對(duì)象組成。內(nèi)存塊的個(gè)數(shù)取決于buffer pool instance的個(gè)數(shù)，不過(guò)在5.7版本中開(kāi)始默認(rèn)以128M(可配置)的chunk單位分配內(nèi)存塊，這樣做的目的是為了支持buffer pool的在線動(dòng)態(tài)調(diào)整大小。
Buffer Pool默認(rèn)情況下是128MB，還是有一點(diǎn)偏小了，我們實(shí)際生產(chǎn)環(huán)境下完全可以對(duì)Buffer Pool進(jìn)行調(diào)整。 比如我們的數(shù)據(jù)庫(kù)如果是16核32G的機(jī)器，那么你就可以給Buffer Pool分配個(gè)2GB的內(nèi)存。

主要配置參數(shù)如下：

• innodb_buffer_pool_size：這個(gè)值是設(shè)置 InnoDB Buffer Pool 的總大??；
• innodb_buffer_pool_chunk_size：當(dāng)增加或減少innodb_buffer_pool_size時(shí)，操作以塊（chunk）形式執(zhí)行，默認(rèn)是128MB。
• innodb_buffer_pool_instances：設(shè)置 InnoDB Buffer Pool 實(shí)例的個(gè)數(shù)，每一個(gè)實(shí)例都有自己獨(dú)立的 list 管理Buffer Pool；
• innodb_old_blocks_pct：默認(rèn) InnoDB Buffer Pool 中點(diǎn)的位置，默認(rèn)值是37，最大100，也就是我們所謂的3/8的位置，可以自己設(shè)置。

這里面有個(gè)關(guān)系要確定一下，最好按照這個(gè)設(shè)置 innodb_buffer_pool_size=innodb_buffer_pool_chunk_size * innodb_buffer_pool_instancesN（N>=1）;
當(dāng)buffer pool比較大的時(shí)候（超過(guò)1G），innodb會(huì)把buffer pool劃分成幾個(gè)instances，這樣可以提高讀寫(xiě)操作的并發(fā)，減少競(jìng)爭(zhēng)。讀寫(xiě)page都使用hash函數(shù)分配給一個(gè)instances。
當(dāng)增加或者減少buffer pool大小的時(shí)候，實(shí)際上是操作的chunk。buffer pool的大小必須是innodb_buffer_pool_chunk_sizeinnodb_buffer_pool_instances的整數(shù)倍，如果不是的話，innodb會(huì)自動(dòng)調(diào)整的。
比如：
如果指定的buffer pool size大小是9G，instances的個(gè)數(shù)是16，chunk默認(rèn)的大小是128M，那么buffer會(huì)自動(dòng)調(diào)整為10G。因?yàn)?216MB/16/128MB = 4.5不是整數(shù)倍，會(huì)自動(dòng)調(diào)整為10240MB/16/128MB=5整數(shù)倍

3.3、Buffer Pool Size 設(shè)置和生效過(guò)程

理想情況下，在給服務(wù)器的其他進(jìn)程留下足夠的內(nèi)存空間的情況下，Buffer Pool Size 應(yīng)該設(shè)置的盡可能大。當(dāng) Buffer Pool Size 設(shè)置的足夠大時(shí)，整個(gè)數(shù)據(jù)庫(kù)就相當(dāng)于存儲(chǔ)在內(nèi)存當(dāng)中，當(dāng)讀取一次數(shù)據(jù)到 Buffer Pool Size 以后，后續(xù)的讀操作就不用再訪問(wèn)磁盤。

設(shè)置方式：
當(dāng)數(shù)據(jù)庫(kù)已經(jīng)啟動(dòng)的情況下，我們可以通過(guò)在線調(diào)整的方式修改 Buffer Pool Size 的大小。
通過(guò)以下語(yǔ)句：SET GLOBAL innodb_buffer_pool_size=402653184;
當(dāng)執(zhí)行這個(gè)語(yǔ)句以后，并不會(huì)立即生效，而是要等所有的事務(wù)全部執(zhí)行成功以后才會(huì)生效；新的連接和事務(wù)必須等其他事務(wù)完全執(zhí)行成功以后，Buffer Pool Size 設(shè)置生效以后才能夠連接成功，不然會(huì)一直處于等待狀態(tài)。
期間，Buffer Pool Size 要完成碎片整理，去除緩存 page 等等操作。在執(zhí)行增加或者減少 Buffer Pool Size 的操作時(shí)，操作會(huì)作為一個(gè)執(zhí)行塊執(zhí)行，innodb_buffer_pool_chunk_size 的大小會(huì)定義一個(gè)執(zhí)行塊的大小，默認(rèn)的情況下，這個(gè)值是128M。
Buffer Pool Size 的大小最好設(shè)置為 innodb_buffer_pool_chunk_size/ innodb_buffer_pool_instances 的整數(shù)倍，而且是大于等于1。
如果我們要查 Buffer Pool 的狀態(tài)的話，可以使用一下sql:
SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
可以幫我們查看到狀態(tài)。我們可以看一下增加 Buffer Pool 的時(shí)候的一個(gè)過(guò)程，再看一下減少的時(shí)候的日志，其實(shí)還是很好理解的，我們可以看成每次增大或者減少 Buffer Pool 的時(shí)候就是進(jìn)行 innodb_buffer_pool_chunk 的增加或者釋放，按照 innodb_buffer_pool_chunk_size 設(shè)定值的大小增加或者釋放執(zhí)行塊。

• 增加的過(guò)程： 增加執(zhí)行塊，指定新地址，將新加入的執(zhí)行塊加入到 free list（控制執(zhí)行塊的一個(gè)列表）。
• 減少的過(guò)程： 重新整理 Buffer Pool 和空閑頁(yè)，將數(shù)據(jù)從塊中移除，指定新地址。

3.4、Buffer Pool Instances

在64位操作系統(tǒng)的情況下，可以拆分緩沖池成多個(gè)部分，這樣可以在高并發(fā)的情況下最大可能的減少爭(zhēng)用。
配置多個(gè) Buffer Pool Instances 能在很大程度上能夠提高 MySQL 在高并發(fā)的情況下處理事物的性能，優(yōu)化不同連接讀取緩沖頁(yè)的爭(zhēng)用。
我們可以通過(guò)設(shè)置 innodb_buffer_pool_instances 來(lái)設(shè)置 Buffer Pool Instances。當(dāng) InnoDB Buffer Pool 足夠大的時(shí)候，你能夠從內(nèi)存中讀取時(shí)候能有一個(gè)較好的性能，但是也有可能碰到多個(gè)線程同時(shí)請(qǐng)求緩沖池的瓶頸。這個(gè)時(shí)候設(shè)置多個(gè) Buffer Pool Instances 能夠盡量減少連接的爭(zhēng)用。
這能夠保證每次從內(nèi)存讀取的頁(yè)都對(duì)應(yīng)一個(gè) Buffer Pool Instances，而且這種對(duì)應(yīng)關(guān)系是一個(gè)隨機(jī)的關(guān)系。并不是熱數(shù)據(jù)存放在一個(gè) Buffer Pool Instances下，內(nèi)部也是通過(guò) hash 算法來(lái)實(shí)現(xiàn)這個(gè)隨機(jī)數(shù)的。每一個(gè) Buffer Pool Instances 都有自己的 free lists，LRU 和其他的一些 Buffer Pool 的數(shù)據(jù)結(jié)構(gòu)，各個(gè) Buffer Pool Instances 是相對(duì)獨(dú)立的。
innodb_buffer_pool_instances 的設(shè)置必須大于1才算得上是多配置，但是這個(gè)功能起作用的前提是innodb_buffer_pool_size 的大小必須大于1G，理想情況下 innodb_buffer_pool_instances 的每一個(gè) instance 都保證在1G以上。

3.5、SHOW ENGINE INNODB STATUS

當(dāng)你的數(shù)據(jù)庫(kù)啟動(dòng)之后，你隨時(shí)可以通過(guò)上述命令，去查看當(dāng)前innodb里的一些具體情況，執(zhí)行:
SHOW ENGINE INNODB STATUS
就可以了。此時(shí)你可能會(huì)看到如下一系列的東西：

下面解釋一下這里的東西，主要講解這里跟buffer pool相關(guān)的一些東西。

• Total memory allocated，這就是說(shuō)buffer pool最終的總大小是多少
• Buffer pool size，這就是說(shuō)buffer pool一共能容納多少個(gè)緩存頁(yè)
• Free buffers，這就是說(shuō)free鏈表中一共有多少個(gè)空閑的緩存頁(yè)是可用的
• Database pages和Old database pages，就是說(shuō)lru鏈表中一共有多少個(gè)緩存頁(yè)，以及冷數(shù)據(jù)區(qū)域里的緩存頁(yè)數(shù)量
• Modified db pages，這就是flush鏈表中的緩存頁(yè)數(shù)量
• Pending reads和Pending writes，等待從磁盤上加載進(jìn)緩存頁(yè)的數(shù)量，還有就是即將從lru鏈表中刷入磁盤的數(shù)量、即將從flush鏈表中刷入磁盤的數(shù)量
• Pages made young和not young，這就是說(shuō)已經(jīng)lru冷數(shù)據(jù)區(qū)域里訪問(wèn)之后轉(zhuǎn)移到熱數(shù)據(jù)區(qū)域的緩存頁(yè)的數(shù) 量，以及在lru冷數(shù)據(jù)區(qū)域里1s內(nèi)被訪問(wèn)了沒(méi)進(jìn)入熱數(shù)據(jù)區(qū)域的緩存頁(yè)的數(shù)量
• youngs/s和not youngs/s，這就是說(shuō)每秒從冷數(shù)據(jù)區(qū)域進(jìn)入熱數(shù)據(jù)區(qū)域的緩存頁(yè)的數(shù)量，以及每秒在冷數(shù)據(jù)區(qū)域里被訪問(wèn)了但是不能進(jìn)入熱數(shù)據(jù)區(qū)域的緩存頁(yè)的數(shù)量
• Pages read xxxx, created xxx, written xxx，xx reads/s, xx creates/s, 1xx writes/s，這里就是說(shuō)已經(jīng)讀取、創(chuàng)建和寫(xiě)入了多少個(gè)緩存頁(yè)，以及每秒鐘讀取、創(chuàng)建和寫(xiě)入的緩存頁(yè)數(shù)量
• Buffer pool hit rate xxx / 1000，這就是說(shuō)每1000次訪問(wèn)，有多少次是直接命中了buffer pool里的緩存的
• young-making rate xxx / 1000 not xx / 1000，每1000次訪問(wèn)，有多少次訪問(wèn)讓緩存頁(yè)從冷數(shù)據(jù)區(qū)域移動(dòng)到了熱數(shù)據(jù)區(qū)域，以及沒(méi)移動(dòng)的緩存頁(yè)數(shù)量
• LRU len：這就是lru鏈表里的緩存頁(yè)的數(shù)量
• I/O sum：最近50s讀取磁盤頁(yè)的總數(shù)
• I/O cur：現(xiàn)在正在讀取磁盤頁(yè)的數(shù)量

三、buffer pool的空間管理

緩沖池也是有大小限制的，那么既然緩沖池有大小限制的，每次都讀入的數(shù)據(jù)頁(yè)怎么來(lái)管理呢？這里我們來(lái)聊聊緩沖池的空間管理，其實(shí)對(duì)緩沖池進(jìn)行管理的關(guān)鍵部分是如何安排進(jìn)池的數(shù)據(jù)并且按照一定的策略淘汰池中的數(shù)據(jù)，保證池中的數(shù)據(jù)不溢出，同時(shí)還能保證常用數(shù)據(jù)留在池子中。

1、傳統(tǒng) LRU 淘汰法

緩沖池是基于傳統(tǒng)的 LRU 方法來(lái)進(jìn)行緩存頁(yè)管理的，我們先來(lái)看下如果使用 LRU 是如何管理的。
LRU，全稱是 Least Recently Used，中文名字叫作「最近最少使用」。從名字上就很容易理解了。
這里分兩種情況：

1.1、緩存頁(yè)已在緩沖池中

這種情況下會(huì)將對(duì)應(yīng)的緩存頁(yè)放到 LRU 鏈表的頭部，無(wú)需從磁盤再進(jìn)行讀取，也無(wú)需淘汰其它緩存頁(yè)。
如下圖所示，如果要訪問(wèn)的數(shù)據(jù)在 6 號(hào)頁(yè)中，則將 6 號(hào)頁(yè)放到鏈表頭部即可，這種情況下沒(méi)有緩存頁(yè)被淘汰。

1.2、緩存頁(yè)不在緩沖池中

緩存頁(yè)不在緩沖中，這時(shí)候就需要從磁盤中讀入對(duì)應(yīng)的數(shù)據(jù)頁(yè)，將其放置在鏈表頭部，同時(shí)淘汰掉末尾的緩存頁(yè)
如下圖所示，如果要訪問(wèn)的數(shù)據(jù)在 60 號(hào)頁(yè)中，60 號(hào)頁(yè)不在緩沖池中，此時(shí)加載進(jìn)來(lái)放到鏈表的頭部，同時(shí)淘汰掉末尾的 17 號(hào)緩存頁(yè)。

簡(jiǎn)單的LRU算法會(huì)帶來(lái)幾個(gè)問(wèn)題：

• **預(yù)讀失效：**上面我們提到了緩沖池的預(yù)讀機(jī)制可能會(huì)預(yù)先加載相鄰的數(shù)據(jù)頁(yè)。假如加載了 20、21 相鄰的兩個(gè)數(shù)據(jù)頁(yè)，如果只有頁(yè)號(hào)為 20 的緩存頁(yè)被訪問(wèn)了，而另一個(gè)緩存頁(yè)卻沒(méi)有被訪問(wèn)。此時(shí)兩個(gè)緩存頁(yè)都在鏈表的頭部，但是為了加載這兩個(gè)緩存頁(yè)卻淘汰了末尾的緩存頁(yè)，而被淘汰的緩存頁(yè)卻是經(jīng)常被訪問(wèn)的。這種情況就是預(yù)讀失效，被預(yù)先加載進(jìn)緩沖池的頁(yè)，并沒(méi)有被訪問(wèn)到，這種情況是不是很不合理。
• **緩沖池污染 **：還有一種情況是當(dāng)執(zhí)行一條 SQL 語(yǔ)句時(shí)，如果掃描了大量數(shù)據(jù)或是進(jìn)行了全表掃描，此時(shí)緩沖池中就會(huì)加載大量的數(shù)據(jù)頁(yè)，從而將緩沖池中已存在的所有頁(yè)替換出去，這種情況同樣是不合理的。這就是緩沖池污染，并且還會(huì)導(dǎo)致 MySQL 性能急劇下降。

2、冷熱數(shù)據(jù)分離

傳統(tǒng)的 LRU 方法并不能滿足緩沖池的空間管理。因此，Msyql 基于 LRU 設(shè)計(jì)了冷熱數(shù)據(jù)分離的處理方案。
也就是將 LRU 鏈表分為兩部分，一部分為熱數(shù)據(jù)區(qū)域，一部分為冷數(shù)據(jù)區(qū)域。

當(dāng)數(shù)據(jù)頁(yè)第一次被加載到緩沖池中的時(shí)候，先將其放到冷數(shù)據(jù)區(qū)域的鏈表頭部，1s（由 innodb_old_blocks_time 參數(shù)控制） 后該緩存頁(yè)被訪問(wèn)了再將其移至熱數(shù)據(jù)區(qū)域的鏈表頭部。

為什么要等 1s 后才將其移至熱數(shù)據(jù)區(qū)域呢？

如果數(shù)據(jù)頁(yè)剛被加載到冷數(shù)據(jù)區(qū)就被訪問(wèn)了，之后再也不訪問(wèn)它了呢？這不就造成熱數(shù)據(jù)區(qū)的浪費(fèi)了嗎？要是 1s 后不訪問(wèn)了，說(shuō)明之后可能也不會(huì)去頻繁訪問(wèn)它，也就沒(méi)有移至熱緩沖區(qū)的必要了。當(dāng)緩存頁(yè)不夠的時(shí)候，從冷數(shù)據(jù)區(qū)淘汰它們就行了。

另一種情況，當(dāng)我的數(shù)據(jù)頁(yè)已經(jīng)在熱緩沖區(qū)了，是不是緩存頁(yè)只要被訪問(wèn)了就將其插到鏈表頭部呢？不用我說(shuō)你肯定也覺(jué)得不合理。熱數(shù)據(jù)區(qū)域里的緩存頁(yè)是會(huì)被經(jīng)常訪問(wèn)的，如果每訪問(wèn)一個(gè)緩存頁(yè)就插入一次鏈表頭，那整個(gè)熱緩沖區(qū)里就異常騷動(dòng)了，所以，Mysql 中優(yōu)化為熱數(shù)據(jù)區(qū)的后 3/4 部分被訪問(wèn)后才將其移動(dòng)到鏈表頭部去，對(duì)于前 1/4 部分的緩存頁(yè)被訪問(wèn)了不會(huì)進(jìn)行移動(dòng)。

四、Buffer Pool預(yù)讀機(jī)制

預(yù)讀是mysql提高性能的一個(gè)重要的特性。預(yù)讀就是 IO 異步讀取多個(gè)頁(yè)數(shù)據(jù)讀入 Buffer Pool 的一個(gè)過(guò)程，并且這些頁(yè)被認(rèn)為是很快就會(huì)被讀取到的。InnoDB使用兩種預(yù)讀算法來(lái)提高I/O性能：線性預(yù)讀（linear read-ahead）和隨機(jī)預(yù)讀（randomread-ahead）
為了區(qū)分這兩種預(yù)讀的方式，我們可以把線性預(yù)讀放到以extent為單位，而隨機(jī)預(yù)讀放到以extent中的page為單位。線性預(yù)讀著眼于將下一個(gè)extent提前讀取到buffer pool中，而隨機(jī)預(yù)讀著眼于將當(dāng)前extent中的剩余的page提前讀取到buffer pool中。

Linear線性預(yù)讀

線性預(yù)讀的單位是extend，一個(gè)extend中有64個(gè)page。線性預(yù)讀的一個(gè)重要參數(shù)innodb_read_ahead_threshold，是指在連續(xù)訪問(wèn)多少個(gè)頁(yè)面之后，把下一個(gè)extend讀入到buffer pool中，不過(guò)預(yù)讀是一個(gè)異步的操作。當(dāng)然這個(gè)參數(shù)不能超過(guò)64，因?yàn)橐粋€(gè)extend最多只有64個(gè)頁(yè)面。
例如，innodb_read_ahead_threshold = 56，就是指在連續(xù)訪問(wèn)了一個(gè)extend的56個(gè)頁(yè)面之后把下一個(gè)extend讀入到buffer pool中。在添加此參數(shù)之前，InnoDB僅計(jì)算當(dāng)它在當(dāng)前范圍的最后一頁(yè)中讀取時(shí)是否為整個(gè)下一個(gè)范圍發(fā)出異步預(yù)取請(qǐng)求。

Random隨機(jī)預(yù)讀

隨機(jī)預(yù)讀方式則是表示當(dāng)同一個(gè)extent中的一些page在buffer pool中發(fā)現(xiàn)時(shí)，Innodb會(huì)將該extent中的剩余page一并讀到buffer pool中。由于隨機(jī)預(yù)讀方式給innodb code帶來(lái)了一些不必要的復(fù)雜性，同時(shí)在性能也存在不穩(wěn)定性，在5.5中已經(jīng)將這種預(yù)讀方式廢棄，默認(rèn)是OFF。若要啟用此功能，即將配置變量設(shè)置innodb_random_read_ahead為ON。

五、Buffer Pool的三種Page和鏈表

Buffer Pool 是Innodb 內(nèi)存中的的一塊占比較大的區(qū)域，用來(lái)緩存表和索引數(shù)據(jù)。眾所周知，從內(nèi)存訪問(wèn)會(huì)比從磁盤訪問(wèn)快很多。為了提高數(shù)據(jù)的讀取速度，Buffer Pool 會(huì)通過(guò)三種Page 和鏈表來(lái)管理這些經(jīng)常訪問(wèn)的數(shù)據(jù)，保證熱數(shù)據(jù)不被置換出Buffer Pool。

1、三種Page

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

2、三種鏈表

2.1、LRU 鏈表

如上圖所示，是Buffer Pool里面的LRU(least recently used)鏈表。LRU鏈表是被一種叫做最近最少使用的算法管理。
LRU鏈表被分成兩部分：

• New Sublist(Young 鏈表)，用來(lái)存放經(jīng)常被讀取的頁(yè)的地址。
• Old Sublist(Old 鏈表)，用來(lái)存放較少被使用的頁(yè)面。每部分都有對(duì)應(yīng)的頭部和尾部。

默認(rèn)情況下

• Old 鏈表占整個(gè)LRU 鏈表的比例是3/8。該比例由innodb_old_blocks_pct控制，默認(rèn)值是37（3/8*100），該值取值范圍為5~95，為全局動(dòng)態(tài)變量。
• 當(dāng)新的頁(yè)被讀取到Buffer Pool里面的時(shí)候，和傳統(tǒng)的LRU算法插入到LRU鏈表頭部不同，Innodb LRU算法是將新的頁(yè)面插入到Y(jié)ong 鏈表的尾部和Old 鏈表的頭部中間的位置，這個(gè)位置叫做Mid Point。如上圖所示。
• 頻繁訪問(wèn)一個(gè)Buffer Pool的頁(yè)面( innodb_old_blocks_time間隔時(shí)間配置)，會(huì)促使頁(yè)面往Young鏈表的頭部移動(dòng)。如果一個(gè)Page在被讀到Buffer Pool后很快就被訪問(wèn)，那么該P(yáng)age會(huì)往Young List的頭部移動(dòng)，但是如果一個(gè)頁(yè)面是通過(guò)預(yù)讀的方式讀到Buffer Pool，且之后短時(shí)間內(nèi)沒(méi)有被訪問(wèn)，那么很可能在下次訪問(wèn)之前就被移動(dòng)到Old List的尾部，而被驅(qū)逐了。
• 隨著數(shù)據(jù)庫(kù)的持續(xù)運(yùn)行，新的頁(yè)面被不斷的插入到LRU鏈表的Mid Point，Old 鏈表里的頁(yè)面會(huì)逐漸的被移動(dòng)Old鏈表的尾部。同時(shí)，當(dāng)經(jīng)常被訪問(wèn)的頁(yè)面移動(dòng)到LRU鏈表頭部的時(shí)候，那些沒(méi)有被訪問(wèn)的頁(yè)面會(huì)逐漸的被移動(dòng)到鏈表的尾部。最終，位于Old 鏈表尾部的頁(yè)面將被驅(qū)逐。

如果一個(gè)數(shù)據(jù)頁(yè)已經(jīng)處于Young 鏈表，當(dāng)它再次被訪問(wèn)的時(shí)候，只有當(dāng)其處于Young 鏈表長(zhǎng)度的1/4(大約值)之后，才會(huì)被移動(dòng)到Y(jié)oung 鏈表的頭部。這樣做的目的是減少對(duì)LRU 鏈表的修改，因?yàn)長(zhǎng)RU 鏈表的目標(biāo)是保證經(jīng)常被訪問(wèn)的數(shù)據(jù)頁(yè)不會(huì)被驅(qū)逐出去。

移動(dòng)到y(tǒng)oung鏈表的時(shí)間配置：
innodb_old_blocks_time 控制的Old 鏈表頭部頁(yè)面的轉(zhuǎn)移策略。該P(yáng)age需要在Old 鏈表停留超過(guò)innodb_old_blocks_time 時(shí)間，之后再次被訪問(wèn)，才會(huì)移動(dòng)到Y(jié)oung 鏈表。這么操作是避免Young 鏈表被那些只在innodb_old_blocks_time時(shí)間間隔內(nèi)頻繁訪問(wèn)，之后就不被訪問(wèn)的頁(yè)面塞滿，從而有效的保護(hù)Young 鏈表。
在全表掃描或者全索引掃描的時(shí)候，Innodb會(huì)將大量的頁(yè)面寫(xiě)入LRU 鏈表的Mid Point位置，并且只在短時(shí)間內(nèi)訪問(wèn)幾次之后就不再訪問(wèn)了。設(shè)置innodb_old_blocks_time的時(shí)間窗口可以有效的保護(hù)Young List，保證了真正的頻繁訪問(wèn)的頁(yè)面不被驅(qū)逐。
innodb_old_blocks_time 單位是毫秒，默認(rèn)值是1000。調(diào)大該值提高了從Old鏈表移動(dòng)到Y(jié)oung鏈表的難度，會(huì)促使更多頁(yè)面被移動(dòng)到Old 鏈表，老化，從而被驅(qū)逐。
當(dāng)掃描的表很大，Buffer Pool都放不下時(shí)，可以將innodb_old_blocks_pct設(shè)置為較小的值，這樣只讀取一次的數(shù)據(jù)頁(yè)就不會(huì)占據(jù)大部分的Buffer Pool。例如，設(shè)置innodb_old_blocks_pct = 5，會(huì)將僅讀取一次的數(shù)據(jù)頁(yè)在Buffer Pool的占用限制為5％。
當(dāng)經(jīng)常掃描一些小表時(shí)，這些頁(yè)面在Buffer Pool移動(dòng)的開(kāi)銷較小，我們可以適當(dāng)?shù)恼{(diào)大innodb_old_blocks_pct，例如設(shè)置innodb_old_blocks_pct = 50。

在SHOW ENGINE INNODB STATUS 里面提供了Buffer Pool一些監(jiān)控指標(biāo)，有幾個(gè)我們需要關(guān)注一下：

• youngs/s：該指標(biāo)表示的是每秒訪問(wèn)Old 鏈表中頁(yè)面，使其移動(dòng)到Y(jié)oung鏈表的次數(shù)。如果MySQL實(shí)例都是一些小事務(wù)，沒(méi)有大表全掃描，且該指標(biāo)很小，就需要調(diào)大innodb_old_blocks_pct 或者減小innodb_old_blocks_time，這樣會(huì)使得Old List 的長(zhǎng)度更長(zhǎng)，Old頁(yè)面被移動(dòng)到Old List 的尾部消耗的時(shí)間會(huì)更久，那么就提升了下一次訪問(wèn)到Old List里面的頁(yè)面的可能性。如果該指標(biāo)很大，可以調(diào)小innodb_old_blocks_pct，同時(shí)調(diào)innodb_old_blocks_time保護(hù)熱數(shù)據(jù)。
• non-youngs/s：該指標(biāo)表示的是每秒訪問(wèn)Old 鏈表中頁(yè)面，沒(méi)有移動(dòng)到Y(jié)oung鏈表的次數(shù)，因?yàn)槠洳环蟟nnodb_old_blocks_time。如果該指標(biāo)很大，一般情況下是MySQL存在大量的全表掃描。如果MySQL存在大量全表掃描，且這個(gè)指標(biāo)又不大的時(shí)候，需要調(diào)大innodb_old_blocks_time，因?yàn)檫@個(gè)指標(biāo)不大意味著全表掃描的頁(yè)面被移動(dòng)到Y(jié)oung 鏈表了，調(diào)大innodb_old_blocks_time時(shí)間會(huì)使得這些短時(shí)間頻繁訪問(wèn)的頁(yè)面保留在Old 鏈表里面。

臟頁(yè)清除線程：

• 每隔1秒鐘，Page Cleaner線程執(zhí)行LRU List Flush的操作，來(lái)釋放足夠的Free Page。
• innodb_lru_scan_depth 變量控制每個(gè)Buffer Pool實(shí)例每次掃描LRU List的長(zhǎng)度，來(lái)尋找對(duì)應(yīng)的臟頁(yè)，執(zhí)行Flush操作。

2.2、Flush 鏈表

• Flush 鏈表里面保存的都是臟頁(yè)，也會(huì)存在于LRU 鏈表。
• Flush 鏈表是按照oldest_modification排序，值大的在頭部，值小的在尾部
• 當(dāng)有頁(yè)面訪被修改的時(shí)候，使用mini-transaction，對(duì)應(yīng)的page進(jìn)入Flush 鏈表
• 如果當(dāng)前頁(yè)面已經(jīng)是臟頁(yè)，就不需要再次加入Flush list，否則是第一次修改，需要加入Flush 鏈表
• 當(dāng)Page Cleaner線程執(zhí)行flush操作的時(shí)候，從尾部開(kāi)始scan，將一定的臟頁(yè)寫(xiě)入磁盤，推進(jìn)檢查點(diǎn)，減少recover的時(shí)間

SQL 的增刪改查都在 Buffer Pool 中執(zhí)行，慢慢地，Buffer Pool 中的緩存頁(yè)因?yàn)椴粩啾恍薷亩鴮?dǎo)致和磁盤文件中的數(shù)據(jù)不一致了，也就是 Buffer Pool 中會(huì)有很多個(gè)臟頁(yè)，臟頁(yè)里面很多臟數(shù)據(jù)。
所以，MySQL 會(huì)有一條后臺(tái)線程，定時(shí)地將 Buffer Pool 中的臟頁(yè)刷回到磁盤文件中。但是，后臺(tái)線程怎么知道哪些緩存頁(yè)是臟頁(yè)呢，不可能將全部的緩存頁(yè)都往磁盤中刷吧，這會(huì)導(dǎo)致 MySQL 暫停一段時(shí)間。

MySQL 是怎么判斷臟頁(yè)的

我們引入一個(gè)和 free 鏈表類似的 flush 鏈表。他的本質(zhì)也是通過(guò)緩存頁(yè)的描述數(shù)據(jù)塊中的兩個(gè)指針，讓修改過(guò)的緩存頁(yè)的描述數(shù)據(jù)塊能串成一個(gè)雙向鏈表，這兩指針大家可以認(rèn)為是 flush_pre 指針和 flush_next 指針。

下面我用偽代碼來(lái)描述一下：

DescriptionDataBlock{
block_id = block1; // free 鏈表的
free_pre = null;
free_next = null; // flush 鏈表的
flush_pre = null;
flush_next = block2;
}

flush 鏈表也有對(duì)應(yīng)的基礎(chǔ)節(jié)點(diǎn)，也是包含鏈表的頭節(jié)點(diǎn)和尾節(jié)點(diǎn)，還有就是修改過(guò)的緩存頁(yè)的數(shù)量。

FlushListBaseNode{
start = block1;
end = block2;
count = 2;
}

到這里，我們都知道，SQL 的增刪改都會(huì)使得緩存頁(yè)變?yōu)榕K頁(yè)，此時(shí)會(huì)修改臟頁(yè)對(duì)應(yīng)的描述數(shù)據(jù)塊的 flush_pre 指針和 flush_next 指針，使得描述數(shù)據(jù)塊加入到 flush 鏈表中，之后 MySQL 的后臺(tái)線程就可以將這個(gè)臟頁(yè)刷回到磁盤中。

2.3、Free 鏈表

• Free 鏈表存放的是空閑頁(yè)面，初始化的時(shí)候申請(qǐng)一定數(shù)量的頁(yè)面，當(dāng) MySQL 啟動(dòng)后，會(huì)不斷地有 SQL 請(qǐng)求進(jìn)來(lái)，此時(shí)空先的緩存頁(yè)就會(huì)不斷地被使用。
• 在執(zhí)行SQL的過(guò)程中，每次成功load 頁(yè)面到內(nèi)存后，會(huì)判斷Free 鏈表的頁(yè)面是否夠用。如果不夠用的話，就flush LRU 鏈表和Flush 鏈表來(lái)釋放空閑頁(yè)。如果夠用，就從Free 鏈表里面刪除對(duì)應(yīng)的頁(yè)面，在LRU 鏈表增加頁(yè)面，保持總數(shù)不變。

使用原理

free 鏈表，它是一個(gè)雙向鏈表，鏈表的每個(gè)節(jié)點(diǎn)就是一個(gè)個(gè)空閑的緩存頁(yè)對(duì)應(yīng)的描述數(shù)據(jù)塊。他本身其實(shí)就是由 Buffer Pool 里的描述數(shù)據(jù)塊組成的，你可以認(rèn)為是每個(gè)描述數(shù)據(jù)塊里都有兩個(gè)指針，一個(gè)是 free_pre 指針，一個(gè)是 free_next 指針，分別指向自己的上一個(gè) free 鏈表的節(jié)點(diǎn)，以及下一個(gè) free 鏈表的節(jié)點(diǎn)。
通過(guò) Buffer Pool 中的描述數(shù)據(jù)塊的 free_pre 和 free_next 兩個(gè)指針，就可以把所有的描述數(shù)據(jù)塊串成一個(gè) free 鏈表。
下面我們可以用偽代碼來(lái)描述一下 free 鏈表中描述數(shù)據(jù)塊節(jié)點(diǎn)的數(shù)據(jù)結(jié)構(gòu)：

DescriptionDataBlock{
block_id = block1;
free_pre = null;
free_next = block2;
}

free 鏈表有一個(gè)基礎(chǔ)節(jié)點(diǎn)，他會(huì)引用鏈表的頭節(jié)點(diǎn)和尾節(jié)點(diǎn)，里面還存儲(chǔ)了鏈表中有多少個(gè)描述數(shù)據(jù)塊的節(jié)點(diǎn)，也就是有多少個(gè)空閑的緩存頁(yè)。

下面我們也用偽代碼來(lái)描述一下基礎(chǔ)節(jié)點(diǎn)的數(shù)據(jù)結(jié)構(gòu)：

FreeListBaseNode{
start = block01;
end = block03;
count = 2;
}

到此，free 鏈表就介紹完了。上面我們也介紹了 MySQL 啟動(dòng)時(shí) Buffer Pool 的初始流程，接下來(lái)，我會(huì)將結(jié)合剛介紹完的 free 鏈表，講解一下 SQL 進(jìn)來(lái)時(shí)，磁盤數(shù)據(jù)頁(yè)讀取到 Buffer Pool 的緩存頁(yè)的過(guò)程。
但是，我們先要了解一下一個(gè)新概念：數(shù)據(jù)頁(yè)緩存哈希表，它的 key 是表空間+數(shù)據(jù)頁(yè)號(hào)，而 value 是對(duì)應(yīng)緩存頁(yè)的地址。

描述如圖所示：

磁盤數(shù)據(jù)頁(yè)讀取到 Buffer Pool 的緩存頁(yè)的過(guò)程

• 首先，SQL 進(jìn)來(lái)時(shí)，判斷數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)頁(yè)能否在數(shù)據(jù)頁(yè)緩存哈希表里找到對(duì)應(yīng)的緩存頁(yè)。如果找到，將直接在 Buffer Pool 中進(jìn)行增刪改查。
• 如果找不到，則從 free 鏈表中找到一個(gè)空閑的緩存頁(yè)，然后從磁盤文件中讀取對(duì)應(yīng)的數(shù)據(jù)頁(yè)的數(shù)據(jù)到緩存頁(yè)中，并且將數(shù)據(jù)頁(yè)的信息和緩存頁(yè)的地址寫(xiě)入到對(duì)應(yīng)的描述數(shù)據(jù)塊中，然后修改相關(guān)的描述數(shù)據(jù)塊的 free_pre 指針和 free_next 指針，將使用了的描述數(shù)據(jù)塊從 free 鏈表中移除。
• 記得，還要在數(shù)據(jù)頁(yè)緩存哈希表中寫(xiě)入對(duì)應(yīng)的 key-value 對(duì)。最后也是在 Buffer Pool 中進(jìn)行增刪改查。

3、LRU 鏈表和Flush鏈表的區(qū)別

LRU鏈表：

• LRU 鏈表 ，由用戶線程觸發(fā)(MySQL 5.6.2之前)；
• LRU 鏈表，其目的是為了寫(xiě)出LRU 鏈表尾部的臟頁(yè)，釋放足夠的空閑頁(yè)，當(dāng)Buffer Pool滿的時(shí)候，用戶可以立即獲得空閑頁(yè)面，而不需要長(zhǎng)時(shí)間等待；
• LRU 鏈表，其寫(xiě)出的臟頁(yè)，需要從LRU鏈表中刪除，移動(dòng)到Free 鏈表。
• Flush 鏈表由MySQL數(shù)據(jù)庫(kù)InnoDB存儲(chǔ)引擎后臺(tái)srv_master線程處理。(在MySQL 5.6.2之后，都被遷移到Page Cleaner線程中)。
• LRU 鏈表 flush，每次flush的臟頁(yè)數(shù)量較少，基本固定，只要釋放一定的空閑頁(yè)即可；

Flush鏈表：

• Flush 鏈表，其目的是推進(jìn)Checkpoint LSN，使得InnoDB系統(tǒng)崩潰之后能夠快速的恢復(fù)。
• Flush List flush，不需要移動(dòng)page在LRU鏈表中的位置。
• Flush 鏈表 flush，根據(jù)當(dāng)前系統(tǒng)的更新繁忙程度，動(dòng)態(tài)調(diào)整一次flush的臟頁(yè)數(shù)量，量很大。
• 在Flush 鏈表上的頁(yè)面一定在LRU 鏈表上，反之則不成立。

4、觸發(fā)刷臟頁(yè)的條件

• REDO日志快用滿的時(shí)候。由于MySQL更新是先寫(xiě)REDO日志，后面再將數(shù)據(jù)Flush到磁盤，如果REDO日志對(duì)應(yīng)臟數(shù)據(jù)還沒(méi)有刷新到磁盤就被覆蓋的話，萬(wàn)一發(fā)生Crash，數(shù)據(jù)就無(wú)法恢復(fù)了。此時(shí)會(huì)從Flush 鏈表里面選取臟頁(yè)，進(jìn)行Flush。
• 為了保證MySQL中的空閑頁(yè)面的數(shù)量，Page Cleaner線程會(huì)從LRU 鏈表尾部淘汰一部分頁(yè)面作為空閑頁(yè)。如果對(duì)應(yīng)的頁(yè)面是臟頁(yè)的話，就需要先將頁(yè)面Flush到磁盤。
• MySQL中臟頁(yè)太多的時(shí)候。innodb_max_dirty_pages_pct 表示的是Buffer Pool最大的臟頁(yè)比例，默認(rèn)值是75%，當(dāng)臟頁(yè)比例大于這個(gè)值時(shí)會(huì)強(qiáng)制進(jìn)行刷臟頁(yè)，保證系統(tǒng)有足夠可用的Free Page。innodb_max_dirty_pages_pct_lwm參數(shù)控制的是臟頁(yè)比例的低水位，當(dāng)達(dá)到該參數(shù)設(shè)定的時(shí)候，會(huì)進(jìn)行preflush，避免比例達(dá)到innodb_max_dirty_pages_pct 來(lái)強(qiáng)制Flush，對(duì)MySQL實(shí)例產(chǎn)生影響。
• MySQL實(shí)例正常關(guān)閉的時(shí)候，也會(huì)觸發(fā)MySQL把內(nèi)存里面的臟頁(yè)全部刷新到磁盤。

Innodb 的策略是在運(yùn)行過(guò)程中盡可能的多占用內(nèi)存，因此未被使用的頁(yè)面會(huì)很少。當(dāng)我們讀取的數(shù)據(jù)不在Buffer Pool里面時(shí)，就需要申請(qǐng)一個(gè)空閑頁(yè)來(lái)存放。如果沒(méi)有足夠的空閑頁(yè)時(shí)，就必須從LRU 鏈表的尾部淘汰頁(yè)面。如果該頁(yè)面是干凈的，可以直接拿來(lái)用，如果是臟頁(yè)，就需要進(jìn)行刷臟操作，將內(nèi)存數(shù)據(jù)Flush到磁盤。

所以，如果出現(xiàn)以下情況，是很容易影響MySQL實(shí)例的性能：

• 一個(gè)SQL查詢的數(shù)據(jù)頁(yè)需要淘汰的頁(yè)面過(guò)多
• 實(shí)例是個(gè)寫(xiě)多型的MySQL，checkpoint跟不上日志產(chǎn)生量，會(huì)導(dǎo)致更新全部堵塞，TPS跌0。

innodb_io_capacity 參數(shù)定義了Innodb 后臺(tái)任務(wù)的IO能力，例如刷臟操作還有Change Buffer的merge操作等。

Innodb 的三種Page和鏈表的設(shè)計(jì)，保證了我們需要的熱數(shù)據(jù)常駐在內(nèi)存，及時(shí)淘汰不需要的數(shù)據(jù)，提升了我們的查詢速度，同時(shí)不同的刷臟策略也提高了我們的恢復(fù)速度，保證了數(shù)據(jù)安全。

到此這篇關(guān)于mysql的Buffer Pool存儲(chǔ)及原理的文章就介紹到這了,更多相關(guān)mysql的Buffer Pool原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！