目錄
- 一、前言
- 二、MVCC(多版本并發控制機制)
- 2.1、Repeatable Read
- 2.2、Read Commit
- 2.3、MVCC的優勢
- 三、MVCC(實現機制)
- 3.1、select運行棧
- 3.2、read_view的創建過程
- 3.3、行版本可見性
- 3.4、undolog搜索可見版本的過程
- 3.5、read_view創建時機再討論
- 四、MVCC和鎖的同時作用導致的一些現象
- 五、總結
一、前言
作為一個數據庫愛好者,自己動手寫過簡單的SQL解析器以及存儲引擎,但感覺還是不夠過癮。事務處理-概念與技術>>誠然講的非常透徹,但只能提綱挈領,不能讓你玩轉某個真正的數據庫。感謝cmake,能夠讓我在mac上用xcode去debug MySQL,從而能去領略它的各種實現細節。
(注:本文的MySQL采用的是MySQL-5.6.35版本)
二、MVCC(多版本并發控制機制)
隔離性也可以被稱作并發控制、可串行化等。談到并發控制首先想到的就是鎖,MySQL通過使用兩階段鎖的方式實現了更新的可串行化,同時為了加速查詢性能,采用了MVCC(Multi Version Concurrency Control)的機制,使得不用鎖也可以獲取一致性的版本。
2.1、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。
2.2、Read Commit
而如果不通過版本控制機制,而是讀到最近提交的結果的話,則隔離級別是read commit,如下圖所示:

在這種情況下,就需要使用鎖機制(例如select for update)將此A,B記錄鎖住,從而獲得正確的一致結果,如下圖所示:

2.3、MVCC的優勢
當我們要對一些數據做一些只讀操作來檢查一致性,例如檢查賬務是否對齊的操作時候,并不希望加上對性能損耗很大的鎖。這時候MVCC的一致性版本就有很大的優勢了。
三、MVCC(實現機制)
本節就開始談談MVCC的實現機制,注意MVCC僅僅在純select時有效(不包括select for update,lock in share mode等加鎖操作,以及update\insert等)。
3.1、select運行棧
首先我們追蹤一下一條普通的查詢sql在mysql源碼中的運行過程,sql為(select * from test);

其運行棧為:
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過濾的過程)。繼續追蹤:
read_record
|-rr_sequential
|-ha_rnd_next
|-ha_innobase::rnd_next 這邊就已經到了innodb引擎了
|-general_fetch
|-row_search_for_mysql
|-lock_clust_rec_cons_read_sees 這邊就是判斷并選擇版本的地方
讓我們看下該函數內部:
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));
}
3.2、read_view的創建過程
我們先關注一致性視圖的創建過程,我們先看下read_view結構:
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_idtx_idlow_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中操作的,繼續跟蹤調用棧:
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里的一個分支:
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函數:
trx_assign_read_view
|-read_view_open_now
|-read_view_open_now_low
好了,終于到了創建read_view的主要階段,主要過程如下圖所示:

代碼過程為:
static read_view_t* read_view_open_now_low(trx_id_t cr_trx_id,mem_heap_t* heap)
{
read_view_t* view;
// 當前事務系統中max_trx_id(即尚未被分配的trx_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);
}
3.3、行版本可見性
由上面的lock_clust_rec_cons_read_sees可知,行版本可見性由read_view_sees_trx_id函數判斷:
/*********************************************************************//**
Checks if a read view sees the specified transaction.
@return 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的返回:
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{
// 可見,然后返回
}
3.4、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方法返回可見版本:
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記錄就又是一個復雜的過程了,由于篇幅原因,在此略過不表。
3.5、read_view創建時機再討論
在創建一致性視圖的row_search_for_mysql的代碼中
// 只有非鎖模式的select才創建一致性視圖
else if (prebuilt->select_lock_type == LOCK_NONE) { // 創建一致性視圖
trx_assign_read_view(trx);
prebuilt->sql_stat_start = FALSE;
}
trx_assign_read_view中由這么一段代碼
// 一致性視圖在一個事務只創建一次
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源碼的讀者們。
以上就是詳解MySQL多版本并發控制機制(MVCC)源碼的詳細內容,更多關于MySQL 并發控制機制 MVCC的資料請關注腳本之家其它相關文章!
您可能感興趣的文章:- MySQL系列之十 MySQL事務隔離實現并發控制
- mysql的MVCC多版本并發控制的實現
- MySQL高并發生成唯一訂單號的方法實現
- MySQL 加鎖控制并發的方法
- Mysql事務并發問題解決方案
- MySQL 數據庫如何解決高并發問題
- mysql并發控制原理知識點
- mysql多版本并發控制MVCC的實現
- MySQL并發更新數據時的處理方法
- Tomcat+Mysql高并發配置優化講解
- MySQL 到底是如何做到多版本并發的?