MySQL資料持久化過程實例分析

1. 流程簡述

理解MySQL資料的持久化過程，能很好的幫助我們加深對於MySQL底層的理解，在本文，我們以一種通俗的方式梳理一下這個過程，幫助大家建立初步的認識，如果大家有興趣，可以去深入學習與研究這個過程。

MySQL資料的儲存總體上可以分為兩部分，記憶體中的儲存過程以及硬碟的持久化存儲，這裡，就涉及到了記憶體中buffer poll和redo log以及磁碟上的交易日誌和表格結構，在本文中，我們不具體解釋每一部分的具體設計，只是給大家一個概念型的認識：

• buffer poll 是InnoDB引擎快取池的一部分，我們這裡可以簡單理解為資料庫從磁碟讀進記憶體的記憶體區塊的快取；

• redo log是記憶體中的邏輯日誌，記錄了交易的變更操作

• ##交易日誌是磁碟上的食物邏輯日誌

• 表格結構是真正儲存資料的結構

2. 記憶體中的操作

buffer poll中有對於讀入記憶體的資料的緩存，在查詢命令執行時，會優先在快取中查看是否命中，未命中就會從磁碟中將所需的資料讀進來，快取的管理使用的是改良的LRU演算法，這裡不做深入介紹了。

當一條修改指令運行的時候，首先進行的是對於

buffer poll中快取的修改，被修改後的資料會被標記為髒頁，同時，修改的操作也會記錄在redo log中，我們常說的MVCC中的版本鏈就是藉由redo log實現的。

要注意的是，髒頁不是立刻落到磁碟的，而是有可以設定的刷盤控制機制，例如，一個事務執行結算後立刻落盤，按照一定時間定期落盤等等。

在記憶體中的操作都是非持久化的，如果這時發生了意料之外的問題導致系統宕機，資料是還沒有持久化的，所以理論上也不會對資料庫造成破壞性的影響。

3. 磁碟的持久化

3.1 交易日誌的作用

InnoDB在磁碟的持久化分為兩步，第一步是邏輯日誌的存儲，之後再將日誌中的資料刷進磁碟空間。

在討論為什麼要使用邏輯日誌之前，我們需要簡單理解

隨機IO與順序IO的區別：

#尋址過程是磁碟IO中的重要瓶頸，因為它需要將探針移動到需要讀取的位置來讀取磁碟資料。

順序IO是指尋址的空間是連續的，移動距離很短，隨機IO是指我們需要尋找的位址分佈在各處，需要移動很長的距離。

所以，我們能很明晰的結論：將

隨機IO替換為順序IO能有效的提高磁碟IO的效率，邏輯日誌的作用正是如此，由於日誌檔案在磁碟上是連續的，相較於分佈在各處的資料表訊息，IO效率能高出很多。

只要我們在交易日誌中完整更新了操作，那麼這個事務就已經持久化成功了，後續會有專門負責的執行緒將日誌資訊儲存到表結構中。

3.2 表結構的兩步驟儲存

日誌資訊儲存到表結構的過程是分兩步驟進行的，首先，會在表頭的快取區域內進行資料更新，更新完成後，才會在對應的表結構中刷新。

兩步驟儲存的目的是確保資料儲存的強一致性，防止在刷入磁碟的過程中，資料庫宕機導致資料不完整。

表頭的快取區域以及表格結構的儲存區塊都有校驗碼來檢驗資料的完整性，如果前者完整，後者不完整，直接講前者資料在後者中重新刷一份即可解決，如果前者不完整，說明從日誌刷取的過程失敗，重新刷取即可。

以上是MySQL資料持久化過程實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！