一想到並發控制，很多人第一反應就是加鎖，的確，加鎖確實是解決並發問題最常見的方案。但是，其實除了加鎖以外，在資料庫領域，還有一種無鎖的方案可以來實現並發控制，那就是大名鼎鼎的MVCC。

MVCC，是Multiversion Concurrency Control的縮寫，翻譯過來是多版本並發控制，他也是一種並發控制的解決方案。

我們知道，在資料庫中，對數據的操作主要有2中，分別是讀和寫，而在並發場景下，就可能出現以下三種情況：

• 讀-讀並發
• 讀-寫並發
• 寫-寫並發

我們都知道，在沒有寫的情況下發讀-讀並是不會出現問題的，而寫-寫並發這種情況比較常用的就是通過加鎖的方式實現。那麼，讀-寫並發則可以通過MVCC的機制解決。本文就來介紹下一下MySQL中MVCC的實現機制。

快照讀和當前讀

要想搞清楚MVCC的機制，最重要的一個概念那就是快照讀。

所謂快照讀，就是讀取的是快照數據，即快照生成的那一刻的數據，像我們常用的普通的SELECT語句在不加鎖情況下就是快照讀。如：

SELECT * FROM xx_table WHERE ...

和快照讀相對應的另外一個概念叫做當前讀，當前讀就是讀取最新數據，所以，加鎖的 SELECT，或者對數據進行增刪改都會進行當前讀，比如：

SELECT * FROM xx_table LOCK IN SHARE MODE;
SELECT * FROM xx_table FOR UPDATE;
INSERT INTO xx_table ...
DELETE FROM xx_table ...
UPDATE xx_table ...

可以說快照讀是MVCC實現的基礎，而當前讀是悲觀鎖實現的基礎。

那麼，快照讀讀到的快照是從哪裡讀到的的呢？換句話說，快照是存在哪裡的呢？

Undo Log

undo log是Mysql中比較重要的事務日誌之一，顧名思義，undo log是一種用於回退的日誌，在事務沒提交之前，MySQL會先記錄更新前的數據到 undo log日誌文件裡面，當事務回滾時或者資料庫崩潰時，可以利用 undo log來進行回退。

這裡面提到的存在undo log中的」更新前的數據」就是我們前面提到的快照。所以，這也是為什麼很多人說UndoLog是MVCC實現的重要手段的原因。

那麼，一條記錄在同一時刻可能有多個事務在執行，那麼，undo log會有一條記錄的多個快照，那麼在這一時刻發生SELECT要進行快照讀的時候，要讀哪個快照呢？

這就需要用到另外幾個信息了。

隱式欄位

其實，資料庫中的每行記錄中，除了保存了我們自己定義的一些欄位以外，還有一些重要的隱式欄位的：

• db_row_id：隱藏主鍵，如果我們沒有給這個表創建主鍵，那麼會以這個欄位來創建聚簇索引。
• db_trx_id：對這條記錄做了最新一次修改的事務的ID
• db_roll_ptr：回滾指針，指向這條記錄的上一個版本，其實他指向的就是Undo Log中的上一個版本的快照的地址。

因為每一次記錄變更之前都會先存儲一份快照到undo log中，那麼這幾個隱式欄位也會跟著記錄一起保存在undo log中，就這樣，每一個快照中都有有一個db_trx_id欄位記錄了本次變更的事務ID，以及一個db_roll_ptr欄位指向了上一個快照的地址。（db_trx_id和db_roll_ptr是重點，後面還會用到）

這樣，就形成了一個快照鍊表：

有了undo log，又有了幾個隱式欄位，我們好像還是不知道具體應該讀取哪個快照，那怎麼辦呢？

Read View

這時候就需要Read View 登場了，

Read View 主要來幫我們解決可見性的問題的, 即他會來告訴我們本次事務應該看到哪個快照，不應該看到哪個快照。

在 Read View 中有幾個重要的屬性：

• trx_ids，系統當前未提交的事務 ID 的列表。
• low_limit_id，未提交的事務中最大的事務 ID。
• up_limit_id，未提交的事務中最小的事務 ID。
• creator_trx_id，創建這個 Read View 的事務 ID。

每開啟一個事務，我們都會從資料庫中獲得一個事務 ID，這個事務 ID 是自增長的，通過 ID 大小，我們就可以判斷事務的時間順序。

那麼，一個事務應該看到哪些快照，不應該看到哪些快照該如何判斷呢？

其實原則比較簡單，那就是事務ID大的事務應該能看到事務ID小的事務的變更結果，反之則不能！舉個例子：

假如當前有一個事務3想要對某條記錄進行一次快照讀的時候，他會先創建一個Read View，並且把當前所有還未提交的事務的信息記錄下來。比如up_limit_id = 2，low_limit_id = 5，trx_ids= [2,4,5]，creator_trx_id= 6

我們前面說過，每一條記錄上都有一個隱式欄位db_trx_id記錄對這條記錄做了最新一次修改的事務的ID，如db_trx_id = 3；

那麼接下來，資料庫會拿這條記錄db_trx_id和Read View進行可見性比較。

如果db_trx_id<up_limit_id，則說明，在Read View中所有未提交的事務創建之前，db_trx_id = 3的這個事務就已經提交了，並且在這期間，並沒有新的事務提交。所有，這條記錄對當前事務就應該是可見的。

如果，db_trx_id>low_limit_id，則說明，db_trx_id = 3的這個事務是在Read View中所有未提交的事務創建之後才提交的，也就是說，在當前事務開啟之後，有別的事務修改了數據並作了提交。所以，這個記錄對於當前事務來說應該就是不可見的。（不可見怎麼辦呢？後面講）

那麼，還有另外一種情況，那就是up_limit_id > db_trx_id > low_limit_id，這種情況下，會再拿db_trx_id和Read View中的trx_ids進行逐一比較。

如果，db_trx_id在trx_ids列表中，那麼表示在當前事務開啟時，並未提交的某個事務在修改數據之後提交了，那麼這個記錄對於當前事務來說應該是不可見的。

如果，db_trx_id不在trx_ids列表中，那麼表示的是在當前事務開啟之前，其他事務對數據進行修改並提交了，所有，這條記錄對當前事務就應該是可見的。

所以，當讀取一條記錄的時候，經過以上判斷，發現記錄對當前事務可見，那麼就直接返回就行了。那麼如果不可見怎麼辦？沒錯，那就需要用到undo log了。

當數據的事務ID不符合Read View規則時候，那就需要從undo log裡面獲取數據的歷史快照，然後數據快照的事務ID再來和Read View進行可見性比較，如果找到一條快照，則返回，找不到則返回空。

所以，總結一下，在InnoDB中，MVCC就是通過Read View + Undo Log來實現的，undo log中保存了歷史快照，而Read View 用來判斷具體哪一個快照是可見的。

MVCC和隔離級別

其實，根據不同的事務隔離級別，Read View的獲取時機是不同的，在RC下，一個事務中的每一次SELECT都會重新獲取一次Read View，而在RR下，一個事務中只在第一次SELECT的時候會獲取一次Read View。

所以，可重複讀這種事務隔離級別之下，因為有MVCC機制，就可以解決不可重複讀的問題，因為他只有在第一次SELECT的時候才會獲取一次Read View，天然不存在重複讀的問題了。