什么是MVCC

MVCC，全稱Multi-Version Concurrency Control，即多版本并發(fā)控制。MVCC是一種并發(fā)控制的方法，一般在數(shù)據(jù)庫管理系統(tǒng)中，實(shí)現(xiàn)對(duì)數(shù)據(jù)庫的并發(fā)訪問，在編程語言中實(shí)現(xiàn)事務(wù)內(nèi)存。

我們知道，一般情況下我們使用mysql數(shù)據(jù)庫的時(shí)候使用的是Innodb存儲(chǔ)引擎，Innodb存儲(chǔ)引擎是支持事務(wù)的，那么當(dāng)多線程同時(shí)執(zhí)行事務(wù)的時(shí)候，可能會(huì)出現(xiàn)并發(fā)問題。這個(gè)時(shí)候需要一個(gè)能夠控制并發(fā)的方法，MVCC就起到了這個(gè)作用。

Mysql的鎖和事務(wù)隔離級(jí)別

在理解MVCC機(jī)制的原理之前，需要先理解Mysql的鎖機(jī)制和事務(wù)的隔離級(jí)別，拋開MyISAM存儲(chǔ)引擎不談，就Innodb存儲(chǔ)引擎來說，分別有行鎖和表鎖兩種鎖，表鎖就是一次操作鎖住整張表，這樣鎖的粒度最大，但是性能也最低，不會(huì)出現(xiàn)死鎖。行鎖就是一次操作鎖住一行，這樣鎖的粒度小，并發(fā)度高，但是會(huì)出現(xiàn)死鎖。

Innodb的行鎖又分為共享鎖（讀鎖）和排它鎖（寫鎖），當(dāng)一個(gè)事務(wù)對(duì)某一行加了讀鎖時(shí)，允許其他事務(wù)對(duì)這一行進(jìn)行讀操作，但是不允許進(jìn)行寫操作，也不允許其他事務(wù)對(duì)這一行執(zhí)行加寫鎖，但是可以加讀鎖。

當(dāng)一個(gè)事務(wù)對(duì)某一行加了寫鎖時(shí)，不允許其他事務(wù)對(duì)這一行進(jìn)行寫操作，但是可以讀，同時(shí)不允許其他事務(wù)對(duì)這一行加讀寫鎖。

下面來看一下Mysql的事務(wù)隔離級(jí)別，分為以下四種：

1. 讀未提交：一個(gè)事務(wù)可以讀到其他事務(wù)還沒有提交的數(shù)據(jù)，會(huì)出現(xiàn)臟讀。舉個(gè)例子，有一張工資表，事務(wù)A先開啟，然后執(zhí)行查詢id為1的員工的工資，假設(shè)此時(shí)的工資為1000，此時(shí)，事務(wù)B也開啟，執(zhí)行了更新操作，將id為1的員工工資減少了100，但是并未提交事務(wù)。此時(shí)再執(zhí)行事務(wù)A的查詢操作，可以讀到事務(wù)B已經(jīng)更新的數(shù)據(jù)，如果此時(shí)事務(wù)B發(fā)生回滾，事務(wù)A讀到的就是“臟”數(shù)據(jù)。當(dāng)事務(wù)A執(zhí)行更新操作的話還可能產(chǎn)生幻讀的情況。
2. 讀已提交：一個(gè)事務(wù)只能讀到另一個(gè)已經(jīng)提交的事務(wù)修改過的數(shù)據(jù)，并且其他事務(wù)每對(duì)該數(shù)據(jù)進(jìn)行一次修改并提交后，該事務(wù)都能查詢得到最新值。還是同樣的例子，這次的事務(wù)隔離級(jí)別為讀已提交的情況下，事務(wù)B不提交事務(wù)的情況下，事務(wù)A無法讀到事務(wù)B更新后的數(shù)據(jù)，也就避免了臟數(shù)據(jù)產(chǎn)生。但是，當(dāng)事務(wù)B提交之后，事務(wù)A再執(zhí)行相同的數(shù)據(jù)，會(huì)發(fā)現(xiàn)數(shù)據(jù)變了，這就是所謂的不可重復(fù)讀，意思就是同一個(gè)事務(wù)中多次執(zhí)行相同的查詢得到的結(jié)果不一致，同時(shí)，幻讀的情況還是存在。
3. 可重復(fù)讀：一個(gè)事務(wù)第一次讀過某條記錄后，即使其他事務(wù)修改了該記錄的值并且提交，該事務(wù)之后再讀該條記錄時(shí)，讀到的仍是第一次讀到的值，而不是每次都讀到不同的數(shù)據(jù)，這就是可重復(fù)讀，這種隔離級(jí)別解決了不可重復(fù)，但是還是會(huì)出現(xiàn)幻讀。
4. 串行化：這種隔離級(jí)別因?yàn)閷?duì)同一條記錄的操作都是串行的，所以不會(huì)出現(xiàn)臟讀、幻讀等現(xiàn)象，但是這也就不是并發(fā)事務(wù)了。

Mysql的undo log

MVCC底層依賴Mysql的undo log，undo log記錄了數(shù)據(jù)庫的操作，因?yàn)閡ndo log是邏輯日志，可以理解為delete一條記錄的時(shí)候，undo log會(huì)記錄一條對(duì)應(yīng)的insert記錄，update一條記錄的時(shí)候，undo log會(huì)記錄一條相反的update記錄，當(dāng)事務(wù)失敗需要回滾操作時(shí)，就可以通過讀取undo log中相應(yīng)的內(nèi)容進(jìn)行回滾，MVCC就利用到了undo log。

MVCC的實(shí)現(xiàn)原理

MVCC的實(shí)現(xiàn)，利用到了數(shù)據(jù)庫的隱式字段，undo log和ReadView。首先來看隱式字段，其實(shí)mysql在表中的每行記錄的后面，都隱式的記錄了DB_TRX_ID（最近修改(修改/插入)事務(wù)ID），DB_ROLL_PTR（回滾指針，指向這條記錄的上一個(gè)版本），DB_ROW_ID（自增ID，如果數(shù)據(jù)表沒有主鍵，則默認(rèn)以此ID簡歷聚簇索引）這幾個(gè)隱藏的字段。

undo log分為兩種，分別為insert undo log，在insert新記錄時(shí)產(chǎn)生的undo log, 只在事務(wù)回滾時(shí)需要，并且在事務(wù)提交后可以被立即丟棄，還有update undo log，事務(wù)在進(jìn)行update或delete時(shí)產(chǎn)生的undo log; 不僅在事務(wù)回滾時(shí)需要，在快照讀時(shí)也需要；所以不能隨便刪除，只有在快速讀或事務(wù)回滾不涉及該日志時(shí)，對(duì)應(yīng)的日志才會(huì)被purge線程統(tǒng)一清除。MVCC利用到的是update undo log。

實(shí)際上undo log記錄的是一個(gè)版本鏈，假設(shè)數(shù)據(jù)庫中有一條記錄如下：

現(xiàn)在有一個(gè)事務(wù)A修改了這條記錄，把name改為tom，這個(gè)時(shí)候的操作流程為：

• 事務(wù)A首先對(duì)該行記錄加上行鎖
• 然后將該行記錄拷貝到undo log中，作為一個(gè)舊的版本
• 拷貝完之后將該行name修改為tom，然后將該行的DB_TRX_ID的值改為事務(wù)A的id，此時(shí)假設(shè)事務(wù)A的id為1，將該行的DB_POLL_PTR指向拷貝到undo log的那條記錄
• 事務(wù)提交后，釋放鎖

此時(shí)的情況如下：

此時(shí)又有一個(gè)事務(wù)B來修改這條記錄，把a(bǔ)ge改為28，這時(shí)候的操作流程為：

• 事務(wù)B對(duì)改行記錄加上行鎖
• 將該行記錄拷貝到undo log中，作為一個(gè)舊的版本，此時(shí)發(fā)現(xiàn)undo log已經(jīng)有記錄了，那么新的一條undo log作為鏈表的表頭插入到該行記錄的undo log的最前面
• 拷貝完后將該行的age改為28，然后將該行的DB_TRX_ID的值改為事務(wù)B的id，此時(shí)假設(shè)事務(wù)B的id為2，將該行的DB_POLL_PTR指向拷貝到undo log的那條記錄
• 事務(wù)提交后釋放鎖
  

此時(shí)的情況如下：

從上面我們可以看到，不同的事務(wù)或者相同的事務(wù)對(duì)同一行記錄進(jìn)行的修改，會(huì)使得該行記錄的undo log形成一個(gè)版本鏈，undo log的鏈?zhǔn)拙褪亲罱淮蔚呐f記錄，而鏈尾就是最早一次的舊記錄。

現(xiàn)在我們來假設(shè)一種情況，先假設(shè)事務(wù)A和事務(wù)B都沒有提交，這時(shí)候有一個(gè)事務(wù)C，修改了name為tom的記錄，把a(bǔ)ge改成了30，然后把事務(wù)提交，事務(wù)C的id為3，同樣的，會(huì)插入一條記錄到undo log中，此時(shí)的undo log版本鏈鏈?zhǔn)子涗浀腄B_TRX_ID為3。

現(xiàn)在有一個(gè)事務(wù)D，查詢name為tom的記錄，此時(shí)將會(huì)啟用快照讀，快照是事務(wù)開始由查詢操作觸發(fā)的一個(gè)數(shù)據(jù)快照，不加鎖的讀在可重復(fù)讀隔離級(jí)別下默認(rèn)就是快照讀，相對(duì)于快照讀還有一個(gè)叫做當(dāng)前讀，更新操作都是當(dāng)前讀。在快照讀時(shí)會(huì)產(chǎn)生一個(gè)讀視圖（Read view），在該事務(wù)執(zhí)行快照讀的那一刻，會(huì)生成數(shù)據(jù)庫當(dāng)前的一個(gè)快照，記錄并且維護(hù)當(dāng)前活躍的事務(wù)的ID，因?yàn)槭聞?wù)的ID都是自增的，所以越新的事務(wù)ID越大。讀視圖遵循可見性算法，而是否可見則需要做一些判斷，讀視圖中除了記錄當(dāng)前活躍的事務(wù)ID以外，還記錄了當(dāng)前創(chuàng)建的最大事務(wù)ID，快照讀時(shí)需要和Read view做比較來獲得可見性結(jié)果。

Read view主要是把當(dāng)前事務(wù)的ID，和系統(tǒng)中的活躍事務(wù)的ID作比較，比較的規(guī)則如下：

首先，Read view中會(huì)有一個(gè)Read view生成時(shí)刻系統(tǒng)中活躍的事務(wù)ID的數(shù)組，暫稱為id_list

然后Read view中會(huì)記錄一個(gè)id_list中最小的事務(wù)ID，暫稱為low_id

最后Read view中還會(huì)記錄一個(gè)Read view生成時(shí)刻系統(tǒng)中尚未分配的事務(wù)ID，也就是當(dāng)前最大的事務(wù)ID+1，暫稱為high_id

• 當(dāng)前事務(wù)ID如果小于low_id，則當(dāng)前事務(wù)可見
• 當(dāng)前事務(wù)ID如果大于high_id，則當(dāng)前事務(wù)不可見
• 當(dāng)前事務(wù)大于low_id小于high_id，再判斷是否在id_list中，如果在，說明活躍的事務(wù)還沒提交，當(dāng)前事務(wù)不可見，但是對(duì)于活躍的事務(wù)本身可見，如果不在id_list中，則當(dāng)前事務(wù)可見

如果可見性結(jié)果為不可見的話，需要通過DB_ROLL_PTR到undo log中取出該記錄的DB_TRX_ID進(jìn)行比較，通過遍歷版本鏈，直到找到滿足特定條件的DB_TRX_ID, 那么這個(gè)DB_TRX_ID所在的舊記錄就是當(dāng)前事務(wù)能看見的最新老版本。

以上就是Mysql MVCC機(jī)制原理詳解的詳細(xì)內(nèi)容，更多關(guān)于Mysql MVCC機(jī)制原理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！