淺析MySQL - MVCC
版本鏈
在InnoDB引擎表中,他們的聚簇索引記錄中有兩個隱藏列:
- trx_id:用來儲存對資料進行修改時的事務id
- roll_pointer:每次對哪條聚簇索引記錄有修改的時候,就會把老版本寫入undo日誌中。這個roll_pointer就是存了一個指標,它指向這條聚簇索引記錄的上一個版本的位置,通過它來獲得上一個版本的記錄資訊。
id | name | trx_id | roll_pointer |
---|---|---|---|
1 | 小明 | 50 | 0x00af |
例如目前有個trx_id是60的事務正執行如下語句: update table set name = '小明1' where id = 1
此時在 undo 日誌中就存在版本鏈
id | name | trx_id | roll_pointer |
---|---|---|---|
1 | 小明1 | 60 | last_version |
↓指向 | |||
1 | 小明 | 50 | null |
版本鏈可以類似git一樣,對一行的資料進行版本控制,可以通過 undo_log進行回滾操作
ReadView
已提交讀和可重複讀的區別就在於它們生成ReadView的策略不同。
ReadView中主要就是有個列表來儲存我們系統中當前活躍的讀寫事務( begin未 commit 的 tx)。通過這個列表來判斷記錄的某個版本是否對當前事務可見。假設當前列表裡的事務 id 為[80,100]。
id <= 80(最小事務id) id >= 80 && id <= 100 id >= 100
這些記錄都是去版本鏈裡面找的,先找最近記錄,如果最近這一條記錄事務id不符合條件,不可見的話,再去找上一個版本再比較當前事務的id和這個版本事務id看能不能訪問,以此類推直到返回可見的版本或者結束。
舉個例子 ,在已提交讀隔離級別下:
比如此時有一個事務id為100的事務,修改了name,使得的name等於小明2,但是事務還沒提交。則此時的版本鏈是
id | name | trx_id | roll_pointer |
---|---|---|---|
1 | 小明2 | 100 | last_version |
↓指向 | |||
1 | 小明1 | 60 | last_version |
↓指向 | |||
1 | 小明 | 50 | null |
那此時另一個事務發起了 select 語句要查詢 id 為 1 的記錄,那此時生成的 ReadView 列表只有[100]。那就去版本鏈去找了,首先肯定找最近的一條,發現 trx_id 是 100,也就是 name 為 小明2 的那條記錄,發現在列表內,所以不能訪問。
這時候就通過指標繼續找下一條,name為 小明1 的記錄,發現 trx_id 是 60,小於列表中的最小 id,所以可以訪問,直接訪問結果為 小明1 。
那這時候我們把事務 id 為 100 的事務提交了,並且新建了一個事務 id 為 110 也修改 id 為 1 的記錄,並且不提交事務
-- trx_id = 110 BEGIN; update table set name = '小明3' where id = 1
這時候版本鏈就是
id | name | trx_id | roll_pointer |
---|---|---|---|
1 | 小明3 | 110 | last_version |
↓指向 | |||
1 | 小明2 | 100 | last_version |
↓指向 | |||
1 | 小明1 | 60 | last_version |
↓指向 | |||
1 | 小明 | 50 | null |
這時候之前那個select事務又執行了一次查詢,要查詢id為1的記錄。
不同隔離級別造成此處結果不同
如果你是 已提交讀 隔離級別,這時候你會重新一個ReadView,那你的活動事務列表中的值就變了,變成了[110]。
按照上的說法,你去版本鏈通過trx_id對比查詢到合適的結果就是小明2。
如果你是 可重複讀 隔離級別,這時候你的 ReadView 還是第一次 select 時候生成的 ReadView,也就是列表的值還是[100]。所以 select 的結果是小明1。所以第二次 select 結果和第一次一樣,所以叫 可重複讀 !
這就是Mysql的MVCC,通過版本鏈,實現多版本,可併發讀-寫,寫-讀。通過ReadView生成策略的不同實現不同的隔離級別。
以上就是淺析MySQL - MVCC的詳細內容,更多關於MySQL mvcc的資料請關注我們其它相關文章!