前言
作為一個資料庫愛好者，自己動手寫過簡單的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); 
其執行棧為:
|
1 2 3 4 5 6 7 8 9 10 11 |
handle_one_connection MySQL的網路模型是one request one thread |-do_handle_one_connection |-do_command |-dispatch_command |-mysql_parse 解析SQL |-mysql_execute_command |-execute_sqlcom_select 執行select語句 |-handle_select ...一堆parse join 等的操作，當前並不關心 |-*tab->read_record.read_record 讀取記錄 |
由於mysql預設隔離級別是repeatable_read(RR),所以read_record過載為 rr_sequential(當前我們並不關心select通過index掃描出row之後再通過condition過濾的過程)。繼續追蹤:
|
1 2 3 4 5 6 7 8 |
read_record |-rr_sequential |-ha_rnd_next |-ha_innobase::rnd_next 這邊就已經到了innodb引擎了 |-general_fetch |-row_search_for_mysql |-lock_clust_rec_cons_read_sees 這邊就是判斷並選擇版本的地方 |
讓我們看下該函式內部:
|
1 2 3 4 5 6 7 8 |
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結構:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
struct read_view_t{ // 由於是逆序排列，所以low/up有所顛倒 // 能看到當前行版本的高水位標識,> low_limit_id皆不能看見 trx_id_t low_limit_id; // 能看到當前行版本的低水位標識,< up_limit_id皆能看見 trx_id_t up_limit_id; // 當前活躍事務(即未提交的事務)的數量 ulint n_trx_ids; // 以逆序排列的當前獲取活躍事務id的陣列 // 其up_limit_id<tx_id<low_limit_id trx_id_t* trx_ids; // 建立當前檢視的事務id trx_id_t creator_trx_id; // 事務系統中的一致性檢視連結串列 UT_LIST_NODE_T(read_view_t) view_list; }; |
然後通過debug，發現建立read_view結構也是在上述的rr_sequential中操作的，繼續跟蹤呼叫棧:
|
1 2 3 4 5 6 7 8 |
rr_sequential |-ha_rnd_next |-rnd_next |-index_first 在start_of_scan為true時候走當前分支index_first |-index_read |-row_search_for_mysql |-trx_assign_read_view |
我們看下row_search_for_mysql裡的一個分支:
|
1 2 3 4 5 6 7 |
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函式:
|
1 2 3 4 |
trx_assign_read_view |-read_view_open_now |-read_view_open_now_low |
好了，終於到了建立read_view的主要階段,主要過程如下圖所示:
程式碼過程為:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
static read_view_t* read_view_open_now_low(trx_id_t cr_trx_id,mem_heap_t* heap) { read_view_t* view; // 當前事務系統中最大的事務id設定為low_limit_no view->low_limit_no = trx_sys->max_trx_id; view->low_limit_id = view->low_limit_no; // CreateView建構函式，會將非當前事務和已經在記憶體中提交的事務給剔除，即判斷條件為 // trx->id != m_view->creator_trx_id&& !trx_state_eq(trx, TRX_STATE_COMMITTED_IN_MEMORY)的 // 才加入當前檢視列表 ut_list_map(trx_sys->rw_trx_list, &trx_t::trx_list, CreateView(view)); if (view->n_trx_ids > 0) { // 將當前事務系統中的最小id設定為up_limit_id,因為是逆序排列 view->up_limit_id = view->trx_ids[view->n_trx_ids - 1]; } else { // 如果當前沒有非當前事務之外的活躍事務，則設定為low_limit_id view->up_limit_id = view->low_limit_id; } // 忽略purge事務，purge時，當前事務id是0 if (cr_trx_id > 0) { read_view_add(view); } // 返回一致性檢視 return(view); } |
行版本可見性:
由上面的lock_clust_rec_cons_read_sees可知,行版本可見性由read_view_sees_trx_id函式判斷:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
/*********************************************************************//** Checks if a read view sees the specified transaction. <a href='http://www.jobbole.com/members/wx1409399284'>@return</a> true if sees */ UNIV_INLINE bool read_view_sees_trx_id( /*==================*/ const read_view_t* view, /*!< in: read view */ trx_id_t trx_id) /*!< in: trx id */ { if (trx_id < view->up_limit_id) { return(true); } else if (trx_id >= view->low_limit_id) { return(false); } else { ulint lower = 0; ulint upper = view->n_trx_ids - 1; ut_a(view->n_trx_ids > 0); do { ulint mid = (lower + upper) >> 1; trx_id_t mid_id = view->trx_ids[mid]; if (mid_id == trx_id) { return(FALSE); } else if (mid_id < trx_id) { if (mid > 0) { upper = mid - 1; } else { break; } } else { lower = mid + 1; } } while (lower <= upper); } return(true); } |
其實上述函式就是一個二分法，read_view其實儲存的是當前活躍事務的所有事務id,如果當前行版本對應修改的事務id不在當前活躍事務裡面的話，就返回true,表示當前版本可見，否則就是不可見,如下圖所示。
接上述lock_clust_rec_cons_read_sees的返回:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
if (UNIV_LIKELY(srv_force_recovery < 5) && !lock_clust_rec_cons_read_sees( rec, index, offsets, trx->read_view)){ // 當前處理的是當前版本不可見的情況 // 通過undolog來返回到一致的可見版本 err = row_sel_build_prev_vers_for_mysql( trx->read_view, clust_index, prebuilt, rec, &offsets, &heap, &old_vers, &mtr); } else{ // 可見，然後返回 } |
undolog搜尋可見版本的過程
我們現在考察一下row_sel_build_prev_vers_for_mysql函式:
|
1 2 3 |
row_sel_build_prev_vers_for_mysql |-row_vers_build_for_consistent_read |
主要是呼叫了row_ver_build_for_consistent_read方法返回可見版本:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
dberr_t row_vers_build_for_consistent_read(...) { ...... for(;;){ err = trx_undo_prev_version_build(rec, mtr,version,index,*offsets, heap,&prev_version); ...... trx_id = row_get_rec_trx_id(prev_version, index, *offsets); // 如果當前row版本符合一致性檢視，則返回 if (read_view_sees_trx_id(view, trx_id)) { ...... break; } // 如果當前row版本不符合，則繼續回溯上一個版本(回到for迴圈的地方) version = prev_version; } ...... } |
整個過程如下圖所示:
至於undolog怎麼恢復出對應版本的row記錄就又是一個複雜的過程了，由於篇幅原因，在此略過不表。
read_view建立時機再討論
在建立一致性檢視的row_search_for_mysql的程式碼中
|
1 2 3 4 5 6 |
// 只有非鎖模式的select才建立一致性檢視 else if (prebuilt->select_lock_type == LOCK_NONE) { // 建立一致性檢視 trx_assign_read_view(trx); prebuilt->sql_stat_start = FALSE; } |
trx_assign_read_view中由這麼一段程式碼
|
1 2 3 4 5 6 7 8 |
// 一致性檢視在一個事務只建立一次 if (!trx->read_view) { trx->read_view = read_view_open_now( trx->id, trx->global_read_view_heap); trx->global_read_view = trx->read_view; } |
所以綜合這兩段程式碼，即在一個事務中，只有第一次執行select(不加鎖)的時候才會建立一致性檢視,如下圖所示: 
筆者構造了此種場景模擬過，確實如此。
MVCC和鎖的同時作用導致的一些現象
MySQL是通過MVCC和二階段鎖(2PL)來兼顧效能和一致性的，但是由於MySQL僅僅在select時候才建立一致性檢視，而在update等加鎖操作的時候並不做如此操作，所以就會產生一些詭異的現象。如下圖所示:
如果理解了update不走一致性檢視(read_view)，而select走一致性檢視(read_view)，就可以很好解釋這個現象。 如下圖所示:
總結
MySQL為了兼顧效能和ACID使用了大量複雜的機制，2PL(兩階段鎖)和MVCC就是其實現的典型。幸好可以通過xcode等IDE進行方便的debug，這樣就可以非常精確加便捷的追蹤其各種機制的實現。希望這篇文章能夠幫助到喜歡研究MySQL原始碼的讀者們。