MySQL多版本并發(fā)控制機制源碼分析

本篇內(nèi)容主要講解“MySQL多版本并發(fā)控制機制源碼分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“MySQL多版本并發(fā)控制機制源碼分析”吧!

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、襄城網(wǎng)絡(luò)推廣、微信小程序開發(fā)、襄城網(wǎng)絡(luò)營銷、襄城企業(yè)策劃、襄城品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供襄城建站搭建服務(wù)，24小時服務(wù)熱線：18982081108，官方網(wǎng)址：muchs.cn

MVCC(多版本并發(fā)控制機制)

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

Repeatable Read

MySQL的通過MVCC以及(Next-Key Lock)實現(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。

Read Commit

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

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

MVCC的優(yōu)勢

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

MVCC(實現(xiàn)機制)

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

select運行棧

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

其運行棧為:

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

讓我們看下該函數(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));  }

read_view的創(chuàng)建過程

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

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

我們看下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)不會走MVCC的原因。讓我們進一步分析trx_assign_read_view函數(shù):

好了，終于到了創(chuàng)建read_view的主要階段,主要過程如下圖所示:

代碼過程為:

行版本可見性:

由上面的lock_clust_rec_cons_read_sees可知,行版本可見性由read_view_sees_trx_id函數(shù)判斷:

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

接上述lock_clust_rec_cons_read_sees的返回:

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方法返回可見版本:

整個過程如下圖所示:

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

read_view創(chuàng)建時機再討論

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

trx_assign_read_view中由這么一段代碼

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

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

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)象。 如下圖所示:

到此，相信大家對“MySQL多版本并發(fā)控制機制源碼分析”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

標(biāo)題名稱：MySQL多版本并發(fā)控制機制源碼分析
URL網(wǎng)址：http://muchs.cn/article0/ghicoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、動態(tài)網(wǎng)站、網(wǎng)站收錄、域名注冊、外貿(mào)建站、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)