在MVCC中快照怎么工作的

2024-09-12 20:29:56

字體：大中小

來源：轉載

供稿：網友

　　這篇文章將為大家詳細講解有關MVCC中快照怎么工作的，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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

　　假設一個值從 1 被按順序改成了 2、3、4，在回滾日志里面就會有類似下面的記錄。

　　當前值是 4，但是在查詢這條記錄的時候，不同時刻啟動的事務會有不同的 read-view。如圖中看到的，在視圖 A、B、C 里面，這一個記錄的值分別是 1、2、4，同一條記錄在系統中可以存在多個版本，就是數據庫的多版本并發控制（MVCC）。對于 read-view A，要得到 1，就必須將當前值依次執行圖中所有的回滾操作得到。

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

　　MVCC中快照怎么工作的

　　這樣，對于當前事務的啟動瞬間來說，一個數據版本的 row trx_id，有以下幾種可能：

　　如果落在綠色部分，表示這個版本是已提交的事務或者是當前事務自己生成的，這個數據是可見的；

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

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

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

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

　　那么事務A的ID是100

　　此時對于事務A的視圖數組是這樣的【90 93 95 100】，其中低水位是 90，高水位是100+1=101；

　　假如讀到了ID是104的，大于高水位101，表示這個版本是由將來啟動的事務生成的，是肯定不可見的；

　　讀到了ID是88的，小于低水位90，表示這個版本是已提交的事務或者是當前事務自己生成的，這個數據是可見的；

　　讀到了ID是94的，在低水位和高水位之間，但是不在【90 93 95 100】這個數組里，表示這個版本是已經提交了的事務生成的，可見。

　　讀到了ID是93的，在低水位和高水位之間，這【90 93 95 100】這個數組里，表示這個版本是由還沒提交的事務生成的，不可見；

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

　　所以，我來給你翻譯一下。一個數據版本，對于一個事務視圖來說，除了自己的更新總是可見以外，有三種情況：

　　版本未提交，不可見；

　　版本已提交，但是是在視圖創建后提交的，不可見；

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

　　關于“MVCC中快照怎么工作的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

（編輯：武林網）

上一篇：MVCC的概念是啥

下一篇：咋用docker中logs命令顯示最后幾行