Mysql MVCC機制原理詳解

什麼是MVCC

MVCC,全稱Multi-Version Concurrency Control,即多版本並發控制。MVCC是一種並發控制的方法,一般在數據庫管理系統中,實現對數據庫的並發訪問,在編程語言中實現事務內存。

我們知道,一般情況下我們使用mysql數據庫的時候使用的是Innodb存儲引擎,Innodb存儲引擎是支持事務的,那麼當多線程同時執行事務的時候,可能會出現並發問題。這個時候需要一個能夠控制並發的方法,MVCC就起到瞭這個作用。

Mysql的鎖和事務隔離級別

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

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

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

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

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

Mysql的undo log

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

MVCC的實現原理

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

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

實際上undo log記錄的是一個版本鏈,假設數據庫中有一條記錄如下:

現在有一個事務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中,作為一個舊的版本,此時發現undo log已經有記錄瞭,那麼新的一條undo log作為鏈表的表頭插入到該行記錄的undo log的最前面
  • 拷貝完後將該行的age改為28,然後將該行的DB_TRX_ID的值改為事務B的id,此時假設事務B的id為2,將該行的DB_POLL_PTR指向拷貝到undo log的那條記錄
  • 事務提交後釋放鎖

此時的情況如下:

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

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

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

Read view主要是把當前事務的ID,和系統中的活躍事務的ID作比較,比較的規則如下:

首先,Read view中會有一個Read view生成時刻系統中活躍的事務ID的數組,暫稱為id_list

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

最後Read view中還會記錄一個Read view生成時刻系統中尚未分配的事務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機制原理的資料請關註WalkonNet其它相關文章!