MySQL 數據持久化過程講解

1. 過程簡述

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

MySQL數據的存儲總體上可以分為兩部分,內存中的存儲過程以及硬盤的持久化存儲,這裡,就涉及到瞭內存中buffer pollredo 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 數據持久化過程講解的文章就介紹到這瞭,更多相關MySQL 數據持久化 內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: