一、前言

作為一個數(shù)據(jù)庫愛好者，自己動手寫過簡單的SQL解析器以及存儲引擎，但感覺還是不夠過癮。<<事務(wù)處理-概念與技術(shù)>>誠然講的非常透徹，但只能提綱挈領(lǐng)，不能讓你玩轉(zhuǎn)某個真正的數(shù)據(jù)庫。感謝cmake,能夠讓我在mac上用xcode去debug MySQL,從而能去領(lǐng)略它的各種實(shí)現(xiàn)細(xì)節(jié)。

(注:本文的MySQL采用的是MySQL-5.6.35版本)

二、MVCC(多版本并發(fā)控制機(jī)制)

隔離性也可以被稱作并發(fā)控制、可串行化等。談到并發(fā)控制首先想到的就是鎖，MySQL通過使用兩階段鎖的方式實(shí)現(xiàn)了更新的可串行化，同時為了加速查詢性能，采用了MVCC(Multi Version Concurrency Control)的機(jī)制，使得不用鎖也可以獲取一致性的版本。

2.1、Repeatable Read

MySQL的通過MVCC以及(Next-Key Lock)實(shí)現(xiàn)了可重復(fù)讀(Repeatable Read),其思想(MVCC)就是記錄數(shù)據(jù)的版本變遷，通過精巧的選擇不同數(shù)據(jù)的版本從而能夠?qū)τ脩舫尸F(xiàn)一致的結(jié)果。如下圖所示:

上圖中，(A=50|B=50)的初始版本為1。

1.事務(wù)t1在select A時候看到的版本為1，即A=50

2.事務(wù)t2對A和B的修改將版本升級為2,即A=0,B=100

3.事務(wù)t1再此select B的時候看到的版本還是1, 即B=50

這樣就隔離了版本的影響，A+B始終為100。

2.2、Read Commit

而如果不通過版本控制機(jī)制，而是讀到最近提交的結(jié)果的話，則隔離級別是read commit,如下圖所示:

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

2.3、MVCC的優(yōu)勢

當(dāng)我們要對一些數(shù)據(jù)做一些只讀操作來檢查一致性，例如檢查賬務(wù)是否對齊的操作時候，并不希望加上對性能損耗很大的鎖。這時候MVCC的一致性版本就有很大的優(yōu)勢了。

三、MVCC(實(shí)現(xiàn)機(jī)制)

本節(jié)就開始談?wù)凪VCC的實(shí)現(xiàn)機(jī)制,注意MVCC僅僅在純select時有效(不包括select for update,lock in share mode等加鎖操作,以及update\insert等)。

3.1、select運(yùn)行棧

首先我們追蹤一下一條普通的查詢sql在mysql源碼中的運(yùn)行過程,sql為(select * from test);

其運(yùn)行棧為:

handle_one_connection  MySQL的網(wǎng)絡(luò)模型是one request one thread

 |-do_handle_one_connection

|-do_command

|-dispatch_command

|-mysql_parse 解析SQL

|-mysql_execute_command

|-execute_sqlcom_select 執(zhí)行select語句

|-handle_select

...一堆parse join 等的操作，當(dāng)前并不關(guān)心

|-*tab->read_record.read_record 讀取記錄

由于mysql默認(rèn)隔離級別是repeatable_read(RR),所以read_record重載為
rr_sequential(當(dāng)前我們并不關(guān)心select通過index掃描出row之后再通過condition過濾的過程)。繼續(xù)追蹤:

read_record

 |-rr_sequential

|-ha_rnd_next

|-ha_innobase::rnd_next 這邊就已經(jīng)到了innodb引擎了

|-general_fetch

|-row_search_for_mysql

|-lock_clust_rec_cons_read_sees 這邊就是判斷并選擇版本的地方

讓我們看下該函數(shù)內(nèi)部:

bool lock_clust_rec_cons_read_sees(const rec_t* rec /*由innodb掃描出來的一行*/,....){
	...
	// 從當(dāng)前掃描的行中獲取其最后修改的版本trx_id(事務(wù)id)
	trx_id = row_get_rec_trx_id(rec, index, offsets);
	// 通過參數(shù)(一致性快照視圖和事務(wù)id)決定看到的行快照
	return(read_view_sees_trx_id(view, trx_id));
}

3.2、read_view的創(chuàng)建過程

我們先關(guān)注一致性視圖的創(chuàng)建過程,我們先看下read_view結(jié)構(gòu):

struct read_view_t{
	// 由于是逆序排列，所以low/up有所顛倒
	// 能看到當(dāng)前行版本的高水位標(biāo)識,>= low_limit_id皆不能看見
	trx_id_t	low_limit_id;
	// 能看到當(dāng)前行版本的低水位標(biāo)識,< up_limit_id皆能看見
	trx_id_t	up_limit_id;
	// 當(dāng)前活躍事務(wù)(即未提交的事務(wù))的數(shù)量
	ulint		n_trx_ids;
	// 以逆序排列的當(dāng)前獲取活躍事務(wù)id的數(shù)組
	// 其up_limit_id<tx_id<low_limit_id
	trx_id_t*	trx_ids;	
	// 創(chuàng)建當(dāng)前視圖的事務(wù)id
	trx_id_t	creator_trx_id;
	// 事務(wù)系統(tǒng)中的一致性視圖鏈表
	UT_LIST_NODE_T(read_view_t) view_list;
};

然后通過debug，發(fā)現(xiàn)創(chuàng)建read_view結(jié)構(gòu)也是在上述的rr_sequential中操作的，繼續(xù)跟蹤調(diào)用棧:

rr_sequential

 |-ha_rnd_next

  |-rnd_next

  |-index_first 在start_of_scan為true時候走當(dāng)前分支index_first

  |-index_read

  |-row_search_for_mysql

  |-trx_assign_read_view

我們看下row_search_for_mysql里的一個分支:

row_search_for_mysql:
// 這邊只有select不加鎖模式的時候才會創(chuàng)建一致性視圖
else if (prebuilt->select_lock_type == LOCK_NONE) {		// 創(chuàng)建一致性視圖
		trx_assign_read_view(trx);
		prebuilt->sql_stat_start = FALSE;
}

上面的注釋就是select for update(in share model)不會走M(jìn)VCC的原因。讓我們進(jìn)一步分析trx_assign_read_view函數(shù):

trx_assign_read_view

 |-read_view_open_now

  |-read_view_open_now_low

好了，終于到了創(chuàng)建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;
	// 當(dāng)前事務(wù)系統(tǒng)中max_trx_id(即尚未被分配的trx_id)設(shè)置為low_limit_no
	view->low_limit_no = trx_sys->max_trx_id;
	view->low_limit_id = view->low_limit_no;
	// CreateView構(gòu)造函數(shù)，會將非當(dāng)前事務(wù)和已經(jīng)在內(nèi)存中提交的事務(wù)給剔除，即判斷條件為
	// trx->id != m_view->creator_trx_id&& !trx_state_eq(trx, TRX_STATE_COMMITTED_IN_MEMORY)的
	// 才加入當(dāng)前視圖列表
	ut_list_map(trx_sys->rw_trx_list, &trx_t::trx_list, CreateView(view));
	if (view->n_trx_ids > 0) {
		// 將當(dāng)前事務(wù)系統(tǒng)中的最小id設(shè)置為up_limit_id,因?yàn)槭悄嫘蚺帕?
		view->up_limit_id = view->trx_ids[view->n_trx_ids - 1];
	} else {
		// 如果當(dāng)前沒有非當(dāng)前事務(wù)之外的活躍事務(wù)，則設(shè)置為low_limit_id
		view->up_limit_id = view->low_limit_id;
	}
	// 忽略purge事務(wù)，purge時，當(dāng)前事務(wù)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函數(shù)判斷:

/*********************************************************************//**
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);
}

其實(shí)上述函數(shù)就是一個二分法，read_view其實(shí)保存的是當(dāng)前活躍事務(wù)的所有事務(wù)id,如果當(dāng)前行版本對應(yīng)修改的事務(wù)id不在當(dāng)前活躍事務(wù)里面的話，就返回true,表示當(dāng)前版本可見，否則就是不可見,如下圖所示。

接上述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)){
	// 當(dāng)前處理的是當(dāng)前版本不可見的情況
	// 通過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搜索可見版本的過程

我們現(xiàn)在考察一下row_sel_build_prev_vers_for_mysql函數(shù):

row_sel_build_prev_vers_for_mysql

 |-row_vers_build_for_consistent_read

主要是調(diào)用了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);
		// 如果當(dāng)前row版本符合一致性視圖，則返回
		if (read_view_sees_trx_id(view, trx_id)) {
			......
			break;
		}
		// 如果當(dāng)前row版本不符合，則繼續(xù)回溯上一個版本(回到for循環(huán)的地方)
		version = prev_version;
	}
	......
}

整個過程如下圖所示:

至于undolog怎么恢復(fù)出對應(yīng)版本的row記錄就又是一個復(fù)雜的過程了，由于篇幅原因，在此略過不表。

3.5、read_view創(chuàng)建時機(jī)再討論

在創(chuàng)建一致性視圖的row_search_for_mysql的代碼中

// 只有非鎖模式的select才創(chuàng)建一致性視圖
else if (prebuilt->select_lock_type == LOCK_NONE) {		// 創(chuàng)建一致性視圖
		trx_assign_read_view(trx);
		prebuilt->sql_stat_start = FALSE;
}

trx_assign_read_view中由這么一段代碼

// 一致性視圖在一個事務(wù)只創(chuàng)建一次
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;
	}

所以綜合這兩段代碼，即在一個事務(wù)中，只有第一次運(yùn)行select(不加鎖)的時候才會創(chuàng)建一致性視圖,如下圖所示:

筆者構(gòu)造了此種場景模擬過，確實(shí)如此。

四、MVCC和鎖的同時作用導(dǎo)致的一些現(xiàn)象

MySQL是通過MVCC和二階段鎖(2PL)來兼顧性能和一致性的，但是由于MySQL僅僅在select時候才創(chuàng)建一致性視圖，而在update等加鎖操作的時候并不做如此操作，所以就會產(chǎn)生一些詭異的現(xiàn)象。如下圖所示:

如果理解了update不走一致性視圖(read_view)，而select走一致性視圖(read_view)，就可以很好解釋這個現(xiàn)象。
如下圖所示:

五、總結(jié)

MySQL為了兼顧性能和ACID使用了大量復(fù)雜的機(jī)制，2PL(兩階段鎖)和MVCC就是其實(shí)現(xiàn)的典型。幸好可以通過xcode等IDE進(jìn)行方便的debug，這樣就可以非常精確加便捷的追蹤其各種機(jī)制的實(shí)現(xiàn)。希望這篇文章能夠幫助到喜歡研究MySQL源碼的讀者們。

以上就是詳解MySQL多版本并發(fā)控制機(jī)制(MVCC)源碼的詳細(xì)內(nèi)容，更多關(guān)于MySQL 并發(fā)控制機(jī)制 MVCC的資料請關(guān)注腳本之家其它相關(guān)文章！