MySQL數據持久化過程實例分析

這篇文章主要介紹“MySQL數據持久化過程實例分析”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“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數據持久化過程實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。