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鏈表裡當前有多少個節點。

*磁碟載入頁的流程: *

1. 從free鏈表中取出一個空閑的控制塊（對應緩衝頁）。
2. 把該緩衝頁對應的控制塊的信息填上（例如：頁所在的表空間、頁號之類的信息）。
3. 把該緩衝頁對應的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（最近最少使用）: 就是末尾淘汰法，新數據從鏈表頭部加入，釋放空間時從末尾淘汰.

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

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

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

改進型LRU演算法

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

冷數據區的數據頁什麼時候會被轉到到熱數據區呢 ?

1. 如果該數據頁在LRU鏈表中存在時間超過1s，就將其移動到鏈表頭部 ( 鏈表指的是整個LRU鏈表)
2. 如果該數據頁在LRU鏈表中存在的時間短於1s，其位置不變(由於全表掃描有一個特點，就是它對某個頁的頻繁訪問總耗時會很短)
3. 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;

1. ChangeBuffer用於存儲SQL變更操作，比如Insert/Update/Delete等SQL語句
2. ChangeBuffer中的每個變更操作都有其對應的數據頁，並且該數據頁未載入到緩存中；
3. 當ChangeBuffer中變更操作對應的數據頁載入到緩存中後，InnoDB會把變更操作Merge到數據頁上；
4. InnoDB會定期載入ChangeBuffer中操作對應的數據頁到緩存中，並Merge變更操作

change buffer更新流程

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

1. 更新一條記錄時，該記錄在BufferPool存在，直接在BufferPool修改，一次記憶體操作。

2. 如果該記錄在BufferPool不存在（沒有命中），在不影響數據一致性的前提下，InnoDB 會將這些更新操作緩存在 change buffer 中不用再去磁碟查詢數據，避免一次磁碟IO。

3. 當下次查詢記錄時，會將數據頁讀入記憶體，然後執行change buffer中與這個頁有關的操作.通過這種方式就能保證這個數據邏輯的正確性。

   

寫緩衝區，僅適用於非唯一普通索引頁，為什麼？

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

什麼情況下進行 merge ?

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

1. 訪問這個數據頁會觸發 merge
2. 系統有後臺線程會定期 merge。
3. 在資料庫正常關閉（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