什么是MVCC

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

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

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

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

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

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

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

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

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

MVCC的實現(xiàn)原理

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

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

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

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

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

此時的情況如下：

此時又有一個事務(wù)B來修改這條記錄，把age改為28，這時候的操作流程為：

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

此時的情況如下：

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

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

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

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

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

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

最后Read view中還會記錄一個Read view生成時刻系統(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ù)不可見，但是對于活躍的事務(wù)本身可見，如果不在id_list中，則當(dāng)前事務(wù)可見

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

以上就是Mysql MVCC機制原理詳解的詳細(xì)內(nèi)容，更多關(guān)于Mysql MVCC機制原理的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！