歡迎光臨
每天分享高質量文章

MySQL 多版本併發控制機制(MVCC)原始碼淺析

(點選上方藍字,快速關註我們)


來源:無毀的湖光-Al

my.oschina.net/alchemystar/blog/1927425?tdsourcetag=s_pcqq_aiomsg


前言


作為一個資料庫愛好者,自己動手寫過簡單的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原始碼的讀者們。

【關於投稿】


如果大家有原創好文投稿,請直接給公號傳送留言。


① 留言格式:
【投稿】+《 文章標題》+ 文章連結

② 示例:
【投稿】
《不要自稱是程式員,我十多年的 IT 職場總結》:http://blog.jobbole.com/94148/


③ 最後請附上您的個人簡介哈~



看完本文有收穫?請轉發分享給更多人

關註「資料分析與開發」,提升資料技能

贊(0)

分享創造快樂