什么是MVCC

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

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

Mysql的鎖和事務隔離級別

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

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

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

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

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

Mysql的undo log

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

MVCC的實現(xiàn)原理

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

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

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

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

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

此時的情況如下：

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

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

此時的情況如下：

從上面我們可以看到，不同的事務或者相同的事務對同一行記錄進行的修改，會使得該行記錄的undo log形成一個版本鏈，undo log的鏈首就是最近一次的舊記錄，而鏈尾就是最早一次的舊記錄。

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

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

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

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

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

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

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

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

以上就是Mysql MVCC機制原理詳解的詳細內容，更多關于Mysql MVCC機制原理的資料請關注腳本之家其它相關文章！

最新評論