MySQL之 InnoDB 記憶體結構-有解無憂

從MySQL 5.5版本開始默認使用InnoDB作為引擎，它擅長處理事務，具有自動崩潰恢復的特性，在日常開發中使用非常廣泛
下面是官方的InnoDB引擎架構圖，主要分為記憶體結構和磁盤結構兩大部分，

InnoDB 記憶體結構

1. Buffer Pool

Buffer Pool：緩沖池，簡稱BP，其作用是用來快取表資料與索引資料，減少磁盤IO操作，提升效率，
Buffer Pool由 快取資料頁(Page) 和對快取資料頁進行描述的控制塊 組成, 控制塊中存盤著對應快取頁的所屬的表空間、資料頁的編號、以及對應快取頁在Buffer Pool中的地址等資訊.
Buffer Pool默認大小是128M, 以Page頁為單位，Page頁默認大小16K，而控制塊的大小約為資料頁的5%，大概是800位元組，

注:Buffer Pool大小為128M指的就是快取頁的大小，控制塊則一般占5%，所以每次會多申請6M的記憶體空間用于存放控制塊
如何判斷一個頁是否在BufferPool中快取 ?
MySQl中有一個哈希表資料結構，它使用表空間號+資料頁號，作為一個key，然后緩沖頁對應的控制塊作為value，

當需要訪問某個頁的資料時，先從哈希表中根據表空間號+頁號看看是否存在對應的緩沖頁，
如果有，則直接使用；如果沒有，就從free鏈表中選出一個空閑的緩沖頁，然后把磁盤中對應的頁加載到該緩沖頁的位置

2.Page管理機制

Page頁分類

BufferPool的底層采用鏈表資料結構管理Page，在InnoDB訪問表記錄和索引時會在Page頁中快取，以后使用可以減少磁盤IO操作，提升效率，
Page根據狀態可以分為三種型別：

ree page ：空閑page，未被使用
clean page：被使用page，資料沒有被修改過
dirty page：臟頁，被使用page，資料被修改過，頁中資料和磁盤的資料產生了不一致

Page頁如何管理

針對上面所說的三種page型別，InnoDB通過三種鏈表結構來維護和管理

1. free list 表示空閑緩沖區，管理free page

Buffer Pool的初始化程序中，是先向作業系統申請連續的記憶體空間，然后把它劃分成若干個【控制塊&緩沖頁】的鍵值對，
free鏈表是把所有空閑的緩沖頁對應的控制塊作為一個個的節點放到一個鏈表中，這個鏈表便稱之為free鏈表
基節點: free鏈表中只有一個基節點是不記錄快取頁資訊(單獨申請空間)，它里面就存放了free鏈表的頭節點的地址，尾節點的地址，還有free鏈表里當前有多少個節點，

*磁盤加載頁的流程: *

從free鏈表中取出一個空閑的控制塊（對應緩沖頁），
把該緩沖頁對應的控制塊的資訊填上（例如：頁所在的表空間、頁號之類的資訊），
把該緩沖頁對應的free鏈表節點（即：控制塊）從鏈表中移除，表示該緩沖頁已經被使用了，

2.flush list：表示需要重繪到磁盤的緩沖區，管理dirty page，內部page按修改時間排序，

InnoDB引擎為了提高處理效率，在每次修改緩沖頁后，并不是立刻把修改重繪到磁盤上，而是在未來的某個時間點進行重繪操作. 所以需要使用到flush鏈表存盤臟頁，凡是被修改過的緩沖頁對應的控制塊都會作為節點加入到flush鏈表.
flush鏈表的結構與free鏈表的結構相似

注: 臟頁即存在于flush鏈表，也在LRU鏈表中，但是兩種互不影響，LRU鏈表負責管理page的可用性和釋放，而flush鏈表負責管理臟頁的刷盤操作，

3.lru list：表示正在使用的緩沖區，管理clean page和dirty page，

緩沖區以midpoint為基點，前面鏈表稱為new串列區，存放經常訪問的資料，占63%；后面的鏈表稱為old串列區，存放使用較少資料，占37%

普通LRU演算法

LRU = Least Recently Used（最近最少使用）: 就是末尾淘汰法，新資料從鏈表頭部加入，釋放空間時從末尾淘汰.

當要訪問某個頁時，如果不在Buffer Pool，需要把該頁加載到緩沖池,并且把該緩沖頁對應的控制塊作為節點添加到LRU鏈表的頭部，
當要訪問某個頁時，如果在Buffer Pool中，則直接把該頁對應的控制塊移動到LRU鏈表的頭部
當需要釋放空間時,從最末尾淘汰

普通LRU鏈表的優缺點
優點: 所有最近使用的資料都在鏈表表頭，最近未使用的資料都在鏈表表尾,保證熱資料能最快被獲取到
缺點:

如果發生全表掃描（比如：沒有建立合適的索引 or 查詢時使用select * 等），則有很大可能將真正的熱資料淘汰掉.
由于MySQL中存在預讀機制，很多預讀的頁都會被放到LRU鏈表的表頭，如果這些預讀的頁都沒有用到的話，這樣，會導致很多尾部的緩沖頁很快就會被淘汰，

改進型LRU演算法

改性LRU：鏈表分為new和old兩個部分，加入元素時并不是從表頭插入，而是從中間midpoint位置插入(就是說從磁盤中新讀出的資料會放在冷資料區的頭部)，如果資料很快被訪問，那么page就會向new串列頭部移動，如果資料沒有被訪問，會逐步向old尾部移動，等待淘汰，

冷資料區的資料頁什么時候會被轉到到熱資料區呢 ?

如果該資料頁在LRU鏈表中存在時間超過1s，就將其移動到鏈表頭部 ( 鏈表指的是整個LRU鏈表)
如果該資料頁在LRU鏈表中存在的時間短于1s，其位置不變(由于全表掃描有一個特點，就是它對某個頁的頻繁訪問總耗時會很短)
1s這個時間是由引數 innodb_old_blocks_time 控制的

3. Change Buffer

change Buffer基本概念

Change Buffer：寫緩沖區,是針對二級索引(輔助索引) 頁的更新優化措施，
Change Buffer作用: 在進行DML操作時，如果請求的是輔助索引（非唯一鍵索引）沒有在緩沖池中時，并不會立刻將磁盤頁加載到緩沖池，而是在CB記錄緩沖變更，等未來資料被讀取時，再將資料合并恢復到BP中，
ChangeBuffer占用BufferPool空間，默認占25%，最大允許占50%，可以根據讀寫業務量來進行調整，引數innodb_change_buffer_max_size;

ChangeBuffer用于存盤SQL變更操作，比如Insert/Update/Delete等SQL陳述句
ChangeBuffer中的每個變更操作都有其對應的資料頁，并且該資料頁未加載到快取中；
當ChangeBuffer中變更操作對應的資料頁加載到快取中后，InnoDB會把變更操作Merge到資料頁上；
InnoDB會定期加載ChangeBuffer中操作對應的資料頁到快取中，并Merge變更操作

change buffer更新流程

情況1: 對于唯一索引來說，需要將資料頁讀入記憶體，判斷到沒有沖突，插入這個值，陳述句執行結束；
情況2: 對于普通索引來說，則是將更新記錄在 change buffer，流程如下:

更新一條記錄時，該記錄在BufferPool存在，直接在BufferPool修改，一次記憶體操作，
如果該記錄在BufferPool不存在（沒有命中），在不影響資料一致性的前提下，InnoDB 會將這些更新操作快取在 change buffer 中不用再去磁盤查詢資料，避免一次磁盤IO，
當下次查詢記錄時，會將資料頁讀入記憶體，然后執行change buffer中與這個頁有關的操作.通過這種方式就能保證這個資料邏輯的正確性，

寫緩沖區，僅適用于非唯一普通索引頁，為什么？

如果在索引設定唯一性，在進行修改時，InnoDB必須要做唯一性校驗，因此必須查詢磁盤，做一次IO操作，會直接將記錄查詢到BufferPool中，然后在緩沖池修改，不會在ChangeBuffer操作，

什么情況下進行 merge ?

將 change buffer 中的操作應用到原資料頁，得到最新結果的程序稱為merge .
change buffer，實際上它是可以持久化的資料，也就是說，change buffer 在記憶體中有拷貝，也會被寫入到磁盤上,以下情況會進行持久化:

訪問這個資料頁會觸發 merge
系統有后臺執行緒會定期 merge，
在資料庫正常關閉（shutdown）的程序中，也會執行 merge 操作，

Change Buffer 的使用場景

change buffer 的主要目的就是將記錄的變更動作快取下來,所以在merge發生之前應當盡可能多的快取變更信息,這樣 change buffer的優勢發揮的就越明顯.
應用場景: 對于寫多讀少的業務來說，頁面在寫完以后馬上被訪問到的概率比較小，此時 change buffer 的使用效果最好，這種業務模型常見的就是賬單類、日志類的系統，

4. Log Buffer

Log Buffer：日志緩沖區，用來保存要寫入磁盤上log檔案（Redo/Undo）的資料，日志緩沖區的內容定期重繪到磁盤log檔案中，日志緩沖區滿時會自動將其重繪到磁盤，當遇到BLOB或多行更新的大事務操作時，增加日志緩沖區可以節省磁盤I/O，
LogBuffer主要作用是: 用來優化每次更新操作之后都要寫入redo log 而產生的磁盤IO問題.

LogBuffer空間滿了，會自動寫入磁盤，可以通過將innodb_log_buffer_size引數調大，減少磁盤IO頻率

本文來自博客園，作者：笨笨的二黃子，轉載請注明原文鏈接：https://www.cnblogs.com/zwhdd/p/17268132.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/548526.html

標籤：MySQL

上一篇：干貨分享｜袋鼠云數堆疊離線開發平臺在小檔案治理上的探索實踐之路

下一篇：Oracle入門1