MySQL多版本并發控制機制（MVCC）源碼淺析
前言
作為一個數據庫愛好者，自己動手寫過簡單的SQL解析器以及存儲引擎，但感覺還是不夠過癮。<<事務處理-概念與技術>>誠然講的非常透徹，但只能提綱挈領，不能讓你玩轉某個真正的數據庫。感謝cmake,能夠讓我在mac上用xcode去debug MySQL,從而能去領略它的各種實現細節。
筆者一直對數據庫的隔離性很好奇，此篇博客就是我debug MySQL過程中的偶有所得。
(注:本文的MySQL采用的是MySQL-5.6.35版本)
MVCC(多版本并發控制機制)
隔離性也可以被稱作并發控制、可串行化等。談到并發控制首先想到的就是鎖，MySQL通過使用兩階段鎖的方式實現了更新的可串行化，同時為了加速查詢性能，采用了MVCC(Multi Version Concurrency Control)的機制，使得不用鎖也可以獲取一致性的版本。
Repeatable Read
MySQL的通過MVCC以及(Next-Key Lock)實現了可重復讀(Repeatable Read),其思想(MVCC)就是記錄數據的版本變遷，通過精巧的選擇不同數據的版本從而能夠對用戶呈現一致的結果。如下圖所示:
上圖中，(A=50|B=50)的初始版本為1。
1.事務t1在select A時候看到的版本為1，即A=50
2.事務t2對A和B的修改將版本升級為2,即A=0,B=100
3.事務t1再此select B的時候看到的版本還是1, 即B=50
這樣就隔離了版本的影響，A+B始終為100。
Read Commit
而如果不通過版本控制機制，而是讀到最近提交的結果的話，則隔離級別是read commit,如下圖所示:
在這種情況下，就需要使用鎖機制(例如select for update)將此A,B記錄鎖住，從而獲得正確的一致結果,如下圖所示：
MVCC的優勢
當我們要對一些數據做一些只讀操作來檢查一致性，例如檢查賬務是否對齊的操作時候，并不希望加上對性能損耗很大的鎖。這時候MVCC的一致性版本就有很大的優勢了。
MVCC(實現機制)
本節就開始談談MVCC的實現機制,注意MVCC僅僅在純select時有效(不包括select for update,lock in share mode等加鎖操作,以及updateinsert等)。
select運行棧
首先我們追蹤一下一條普通的查詢sql在mysql源碼中的運行過程,sql為(select * from test);
其運行棧為:
由于mysql默認隔離級別是repeatable_read(RR),所以read_record重載為 rr_sequential(當前我們并不關心select通過index掃描出row之后再通過condition過濾的過程)。繼續追蹤:
讓我們看下該函數內部:
- bool lock_clust_rec_cons_read_sees(const rec_t* rec /*由innodb掃描出來的一行*/,....){
- ...
- // 從當前掃描的行中獲取其***修改的版本trx_id(事務id)
- trx_id = row_get_rec_trx_id(rec, index, offsets);
- // 通過參數(一致性快照視圖和事務id)決定看到的行快照
- return(read_view_sees_trx_id(view, trx_id));
- }
read_view的創建過程
我們先關注一致性視圖的創建過程,我們先看下read_view結構:
然后通過debug，發現創建read_view結構也是在上述的rr_sequential中操作的，繼續跟蹤調用棧:
我們看下row_search_for_mysql里的一個分支:
- row_search_for_mysql:
- // 這邊只有select不加鎖模式的時候才會創建一致性視圖
- else if (prebuilt->select_lock_type == LOCK_NONE) { // 創建一致性視圖
- trx_assign_read_view(trx);
- prebuilt->sql_stat_start = FALSE;
- }
上面的注釋就是select for update(in share model)不會走MVCC的原因。讓我們進一步分析trx_assign_read_view函數:
好了，終于到了創建read_view的主要階段,主要過程如下圖所示:
代碼過程為:
行版本可見性:
由上面的lock_clust_rec_cons_read_sees可知,行版本可見性由read_view_sees_trx_id函數判斷:
其實上述函數就是一個二分法，read_view其實保存的是當前活躍事務的所有事務id,如果當前行版本對應修改的事務id不在當前活躍事務里面的話，就返回true,表示當前版本可見，否則就是不可見,如下圖所示。
接上述lock_clust_rec_cons_read_sees的返回:
undolog搜索可見版本的過程
我們現在考察一下row_sel_build_prev_vers_for_mysql函數:
- row_sel_build_prev_vers_for_mysql
- |-row_vers_build_for_consistent_read
主要是調用了row_ver_build_for_consistent_read方法返回可見版本:
整個過程如下圖所示:
至于undolog怎么恢復出對應版本的row記錄就又是一個復雜的過程了，由于篇幅原因，在此略過不表。
read_view創建時機再討論
在創建一致性視圖的row_search_for_mysql的代碼中
trx_assign_read_view中由這么一段代碼
所以綜合這兩段代碼，即在一個事務中，只有***次運行select(不加鎖)的時候才會創建一致性視圖,如下圖所示:
筆者構造了此種場景模擬過，確實如此。
MVCC和鎖的同時作用導致的一些現象
MySQL是通過MVCC和二階段鎖(2PL)來兼顧性能和一致性的，但是由于MySQL僅僅在select時候才創建一致性視圖，而在update等加鎖操作的時候并不做如此操作，所以就會產生一些詭異的現象。如下圖所示:
如果理解了update不走一致性視圖(read_view)，而select走一致性視圖(read_view)，就可以很好解釋這個現象。 如下圖所示:
總結
MySQL為了兼顧性能和ACID使用了大量復雜的機制，2PL(兩階段鎖)和MVCC就是其實現的典型。幸好可以通過xcode等IDE進行方便的debug，這樣就可以非常精確加便捷的追蹤其各種機制的實現。希望這篇文章能夠幫助到喜歡研究MySQL源碼的讀者們。
