存儲(chǔ)引擎之內(nèi)存管理

在InnoDB存儲(chǔ)引擎中，數(shù)據(jù)庫(kù)中的緩沖池是通過(guò)LRU(Latest Recent Used，最近最少使用)算法來(lái)進(jìn)行管理的，即最頻繁使用的頁(yè)在LRU列表的最前段，而最少使用的頁(yè)在LRU列表的尾端，當(dāng)緩沖池不能存放新讀取到的頁(yè)時(shí)，首先釋放LRU列表尾端的頁(yè)。

上面的圖中，我使用8個(gè)數(shù)據(jù)頁(yè)來(lái)表示隊(duì)列，具體作用，先賣(mài)個(gè)關(guān)子。在InnoDB存儲(chǔ)引擎中，緩沖池中頁(yè)的默認(rèn)大小是16KB，LRU列表中有一個(gè)midpoint的位置，新讀取到的數(shù)據(jù)頁(yè)并不是直接放入到LRU列表的首部，而是放入到LRU列表的midpoint位置，這個(gè)操作稱(chēng)之為midpoint insertion stategy，也叫中間點(diǎn)插入策略。在默認(rèn)配置下，該位置在LRU長(zhǎng)度的5/8處，這也就是上面使用8個(gè)數(shù)據(jù)頁(yè)的作用。下面的圖示意了新的數(shù)據(jù)頁(yè)的插入過(guò)程：

mitpoint的位置可通過(guò)參數(shù)innodb_old_blocks_pct控制，如下：

mysql> show variables like 'innodb_old_blocks_pct';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_old_blocks_pct | 37    |
+-----------------------+-------+
 row in set (. sec)

從上面的例子看出，結(jié)果是37，這個(gè)37意味著新讀取的頁(yè)將被插入到大概距離LRU列表尾端37%的位置，差不多3/8的位置，在InnoDB存儲(chǔ)引擎中，midpoint之前的頁(yè)稱(chēng)為new列表，后面的頁(yè)稱(chēng)之為old列表，new列表中的頁(yè)是最為活躍的數(shù)據(jù)。

為什么不直接把數(shù)據(jù)頁(yè)放在LRU隊(duì)列的首部？

之所以不把新讀取的數(shù)據(jù)頁(yè)放在LRU隊(duì)列的首部，是因?yàn)槟承┤頀呙璧腟QL操作可能會(huì)將所有的熱點(diǎn)數(shù)據(jù)都刷新出LRU隊(duì)列，導(dǎo)致下一次訪問(wèn)熱點(diǎn)數(shù)據(jù)的時(shí)候，必須從磁盤(pán)中取相應(yīng)的數(shù)據(jù)，從而影響緩沖池的效率。為了解決這個(gè)問(wèn)題，InnoDB使用另外一個(gè)參數(shù)來(lái)管理LRU列表，就是innodb_old_blocks_time，用于表示頁(yè)讀取到midpoint之后，多久才會(huì)加入到LRU列表的熱端。因此當(dāng)需要執(zhí)行上述所說(shuō)的SQL操作時(shí)，可以通過(guò)下面的方法盡可能使LRU列表中的熱點(diǎn)數(shù)據(jù)不被刷出。

mysql> set global innodb_old_blocks_time=;
Query OK,  rows affected (0.00 sec)

這表示在1000s之后，才允許這些數(shù)據(jù)刷新到LRU列表的熱端。

如果在實(shí)際情況中，數(shù)據(jù)頁(yè)活躍的比率不止63%，用戶(hù)還可以通過(guò)設(shè)置innodb_old_blocks_pct來(lái)減少熱點(diǎn)頁(yè)可能被刷出的概率。

mysql> set global innodb_old_blocks_pct=;                                                                                                     
Query OK,  rows affected (0.00 sec)

當(dāng)數(shù)據(jù)庫(kù)剛啟動(dòng)時(shí)，LRU的內(nèi)容是空的，這個(gè)時(shí)候，所有的數(shù)據(jù)頁(yè)都放在Free列表中，當(dāng)需要從緩沖池中分頁(yè)時(shí)，首先從Free列表中查找是否有可用的Free頁(yè)，如果存在，則將該頁(yè)從Free頁(yè)中刪除，然后放入到LRU的列表中。淘汰掉LRU列表末尾的數(shù)據(jù)頁(yè)，將該內(nèi)存空間分配給新的頁(yè)。這個(gè)過(guò)程的流程圖如下：

當(dāng)LRU列表中的頁(yè)從old部分加入到new部分時(shí)，稱(chēng)此時(shí)發(fā)生的操作是page made young，而因?yàn)閕nnodb_old_blocks_time的設(shè)置而沒(méi)有從old部分移動(dòng)到new部分的操作稱(chēng)之為page_not_made young?？梢酝ㄟ^(guò)show engine innodb status來(lái)觀察LRU列表以及Free列表的使用情況和運(yùn)行狀態(tài)。

mysql> show engine innodb status\G
***
***
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 
Dictionary memory allocated 
Buffer pool size   
Free buffers       
Database pages     
Old database pages 
Modified db pages  
Pending reads      
Pending writes: LRU , flush list , single page 
Pages made young , not young 
0.00 youngs/s, 0.00 non-youngs/s
Pages read , created , written 
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: , unzip_LRU len: 
I/O sum[]:cur[], unzip sum[]:cur[]
--------------
ROW OPERATIONS
--------------
 queries inside InnoDB,  queries in queue
 read views open inside InnoDB
Process ID=, Main thread ID=, state: sleeping
Number of rows inserted , updated , deleted , read 
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

 row in set (0.00 sec)

    從上面的結(jié)果可以看到：當(dāng)前buffer pool size總共有8191個(gè)頁(yè)，每個(gè)數(shù)據(jù)頁(yè)的大小是16k，總共的大小是8191*16k=128M的緩沖池，其中Free buffers表示當(dāng)前Free列表中頁(yè)的數(shù)量。page made young顯示了LRU列表中頁(yè)移動(dòng)到前端的次數(shù)，因?yàn)樵摲?wù)器在運(yùn)行階段沒(méi)有改變innodb_old_blocks_time的值，因此not young為0，youngs/s、non_youngs/s表示每秒這兩類(lèi)操作的次數(shù)。

    InnoDB存儲(chǔ)引擎從1.0.x版本開(kāi)始支持壓縮頁(yè)的功能，即將原本16kb的數(shù)據(jù)頁(yè)壓縮成1KB、2KB、4KB和8KB。對(duì)于非16KB的頁(yè)，是通過(guò)unzip_LRU來(lái)管理的，上述命令中的第22行就顯示了壓縮頁(yè)和非壓縮頁(yè)的信息。

需要注意的一點(diǎn)是Free buffers的值與Database Pages的值之和不一定等于buffer pool size，因?yàn)榫彌_池中的頁(yè)可能還會(huì)被分配各自適應(yīng)哈希索引、鎖信息等頁(yè)，而這部分頁(yè)并不需要LRU算法進(jìn)行維護(hù)。

臟頁(yè)

     在LRU列表中的頁(yè)被修改之后，這個(gè)頁(yè)就稱(chēng)之為“臟頁(yè)”，即緩沖池中的數(shù)據(jù)頁(yè)和磁盤(pán)上的數(shù)據(jù)產(chǎn)生了不一致，緩沖池的數(shù)據(jù)比較新，這時(shí)數(shù)據(jù)庫(kù)會(huì)通過(guò)checkpoint機(jī)制將臟頁(yè)刷新回磁盤(pán)，而Flush列表中的頁(yè)也就是臟頁(yè)列表，臟頁(yè)既存在于LRU列表中，也存在與Flush列表中，LRU列表用來(lái)管理緩沖池中頁(yè)的可用性，F(xiàn)lush列表用來(lái)管理將頁(yè)刷新回磁盤(pán)，二者不影響。Flush列表也可以通過(guò)show engine innodb status來(lái)查看，前面的結(jié)果列表中的第13行，modified db pages就是當(dāng)前的臟頁(yè)數(shù)量，用戶(hù)可以通過(guò)元數(shù)據(jù)表INNODB_BUFFER_PAGE_LRU表來(lái)查看。

以上就是詳解MySQL InnoDB存儲(chǔ)引擎的內(nèi)存管理的詳細(xì)內(nèi)容，更多關(guān)于InnoDB 內(nèi)存管理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！