淺析MVCC中的快照，看看快照是怎麼運作的？

這篇文章帶大家了解MVCC中的快照，看看快照在MVCC中是怎麼運作的？希望能夠給大家幫忙！

MVCC

在 MySQL 中（innodb儲存引擎），實際上每筆記錄在更新的時候都會同時記錄一個回溯操作。記錄上的最新值，透過回滾操作，都可以得到前一個狀態的值。

假設一個值從 1 被依序改成了 2、3、4，在回溯日誌裡面就會有類似下面的記錄。

目前值是 4，但在查詢這筆記錄的時候，不同時刻啟動的交易會有不同的 read-view。如圖看到的，在視圖A、B、C 裡面，這一個記錄的值分別是1、2、4，同一記錄在系統中可以存在多個版本，就是資料庫的多版本並發控制（MVCC ）。對於 read-view A，要得到 1，就必須將目前值依序執行圖中所有的回溯操作得到。

InnoDB 是怎麼定義一個 ‘快照’

InnoDB 裡面每個事務有一個唯一的交易 ID，叫做 transaction id。 它是在事務開始的時候向 InnoDB 的事務系統申請的，是按申請順序嚴格遞增的。

而每行資料也都是有多個版本的。每次事務更新資料的時候，都會產生一個新的資料版本，並且把 transaction id 賦值給這個資料版本的事務 ID，記為 row trx_id。 同時，舊的資料版本要保留，並且在新的資料版本中，能夠有資訊可以直接拿到它。

也就是說，資料表中的一行記錄，其實可能有多個版本 (row)，每個版本都有自己的 row trx_id。

依照可重複讀取的定義，一個交易啟動的時候，能夠看到所有已經提交的交易結果。但是之後，在這個事務執行期間，其他事務的更新對它不可見。

因此，一個交易只需要在啟動的時候聲明說，「以我啟動的時刻為準，如果一個資料版本是在我啟動之前產生的，就認；如果是我啟動以後才生成的，我就不認，我必須要找到它的上一個版本」。當然，如果「上一個版本」也不可見，那就得繼續往前找。還有，如果是這個事務自己更新的數據，它自己還是要認的。

在實作上， InnoDB 為每個事務建構了一個數組，用來保存這個事務啟動瞬間，目前正在「活躍」的所有事務 ID。 「活躍」指的就是，啟動了但還沒提交。

陣列裡面事務 ID 的最小值記為低水位，目前系統裡面已經建立過的交易 ID 的最大值加 1 記為高水位。

這個視圖陣列把所有的 row trx_id 分成了幾種不同的情況。

這樣，對於目前交易的啟動瞬間來說，一個資料版本的row trx_id，有以下幾種可能：

• 如果落在綠色部分，表示這個版本是已提交的事務或是當前事務自己產生的，這個資料是可見的；

• 如果落在紅色部分，表示這個版本是由將來啟動的交易產生的，是肯定不可見的；

• 如果落在黃色部分，那就包括兩種情況

a. 若row trx_id 在數組中，表示這個版本是由還沒提交的事務產生的，不可見；
b. 若row trx_id 不在數組中，表示這個版本是已經提交了的事務生成的，可見。

舉例：

session A 啟動了一個事務A， 在事務 A 開始前，系統裡面分別有三個活躍事務，ID分別 是90 93 95 。
那麼事務A的ID是100
此時對於事務A的視圖數組是這樣的【90 93 95 100】，其中低水位是90， 高水位是100 1=101;
現在事務A開始讀資料了

• 假如讀到了ID是104的，大於高水位101，表示這個版本是由將來啟動的事務產生的，是肯定不可見的；
• 讀到了ID是88的，小於低水位90，表示這個版本是已提交的事務或者是當前事務自己生成的，這個數據是可見的；
• 讀到了ID是94的，在低水位和高水位之間，但是不在【90 93 95 100】這個數組裡，表示這個版本是已經提交了的事務產生的，可見。
• 讀到了ID是93的，在低水位和高水位之間，這【90 93 95 100】這個數組裡，表示這個版本是由還沒提交的事務生成的，不可見；

這個判斷規則是從程式碼邏輯直接轉譯過來的，但如你所見，用於人肉分析可見性很麻煩。

所以，我來幫你翻譯一下。一個資料版本，對於一個交易視圖來說，除了自己的更新總是可見以外，有三種情況：

• 版本未提交，不可見；

• #版本已提交，但是是在視圖建立後提交的，不可見；

• 版本已提交，而且是在視圖建立前提交的，可見。

【相關推薦：mysql影片教學】

以上是淺析MVCC中的快照，看看快照是怎麼運作的？的詳細內容。更多資訊請關注PHP中文網其他相關文章！