什么是MVCC?
MVCC,全稱Multi-Version Concurrency Control,即多版本并發控制。MVCC是一種并發控制的方法,一般在數據庫管理系統中,實現對數據庫的并發訪問,在編程語言中實現事務內存。 在Mysql的InnoDB引擎中就是指在已提交讀(READ COMMITTD)和可重復讀(REPEATABLE READ)這兩種隔離級別下的事務對于SELECT操作會訪問版本鏈中的記錄的過程。 這就使得別的事務可以修改這條記錄,反正每次修改都會在版本鏈中記錄。SELECT可以去版本鏈中拿記錄,這就實現了讀-寫,寫-讀的并發執行,提升了系統的性能。
MySQL的InnoDB引擎實現MVCC的3個基礎點
1.隱式字段
如上圖,DB_ROW_ID是數據庫默認為該行記錄生成的唯一隱式主鍵;DB_TRX_ID是當前操作該記錄的事務ID; 而DB_ROLL_PTR是一個回滾指針,用于配合undo日志,指向上一個舊版本;delete flag沒有展示出來。
2.undo log
從上面,我們就可以看出,不同事務或者相同事務的對同一記錄的修改,會導致該記錄的undo log成為一條記錄版本線性表,既鏈表,undo log的鏈首就是最新的舊記錄,鏈尾就是最早的舊記錄
3.ReadView
已提交讀和可重復讀的區別就在于它們生成ReadView的策略不同。
ReadView中主要就是有個列表來存儲我們系統中當前活躍著的讀寫事務,也就是begin了還未提交的事務。通過這個列表來判斷記錄的某個版本是否對當前事務可見。假設當前列表里的事務id為[80,100]。
a) 如果你要訪問的記錄版本的事務id為50,比當前列表最小的id80小,那說明這個事務在之前就提交了,所以對當前活動的事務來說是可訪問的。
b) 如果你要訪問的記錄版本的事務id為90,發現此事務在列表id最大值和最小值之間,那就再判斷一下是否在列表內,如果在那就說明此事務還未提交,所以版本不能被訪問。如果不在那說明事務已經提交,所以版本可以被訪問。
c) 如果你要訪問的記錄版本的事務id為110,那比事務列表最大id100都大,那說明這個版本是在ReadView生成之后才發生的,所以不能被訪問。
這些記錄都是去undo log 鏈里面找的,先找最近記錄,如果最近這一條記錄事務id不符合條件,不可見的話,再去找上一個版本再比較當前事務的id和這個版本事務id看能不能訪問,以此類推直到返回可見的版本或者結束。
舉個例子 ,在已提交讀隔離級別下:
比如此時有一個事務id為100的事務,修改了name,使得的name等于小明2,但是事務還沒提交。則此時的版本鏈是
那此時另一個事務發起了select 語句要查詢id為1的記錄,那此時生成的ReadView 列表只有[100]。那就去版本鏈去找了,首先肯定找最近的一條,發現trx_id是100,也就是name為小明2的那條記錄,發現在列表內,所以不能訪問。
這時候就通過指針繼續找下一條,name為小明1的記錄,發現trx_id是60,小于列表中的最小id,所以可以訪問,直接訪問結果為小明1。
那這時候我們把事務id為100的事務提交了,并且新建了一個事務id為110也修改id為1的記錄,并且不提交事務
這時候版本鏈就是
這時候之前那個select事務又執行了一次查詢,要查詢id為1的記錄。
已提交讀隔離級別下的事務在每次查詢的開始都會生成一個獨立的ReadView,而可重復讀隔離級別則在第一次讀的時候生成一個ReadView,之后的讀都復用之前的ReadView。
1.如果你是已提交讀隔離級別,這時候你會重新一個ReadView,那你的活動事務列表中的值就變了,變成了[110]。按照上的說法,你去版本鏈通過trx_id對比查找到合適的結果就是小明2。
2.如果你是可重復讀隔離級別,這時候你的ReadView還是第一次select時候生成的ReadView,也就是列表的值還是[100]。所以select的結果是小明1。所以第二次select結果和第一次一樣,所以叫可重復讀!
這就是Mysql的MVCC,通過版本鏈,實現多版本,可并發讀-寫,寫-讀。通過ReadView生成策略的不同實現不同的隔離級別。