?一想到并發(fā)控制，很多人第一反應(yīng)就是加鎖，的確，加鎖確實是解決并發(fā)問題最常見的方案。但是，其實除了加鎖以外，在數(shù)據(jù)庫領(lǐng)域，還有一種無鎖的方案可以來實現(xiàn)并發(fā)控制，那就是大名鼎鼎的MVCC。

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

我們知道，在數(shù)據(jù)庫中，對數(shù)據(jù)的操作主要有2中，分別是讀和寫，而在并發(fā)場景下，就可能出現(xiàn)以下三種情況：

• 讀-讀并發(fā)
• 讀-寫并發(fā)
• 寫-寫并發(fā)

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

快照讀和當(dāng)前讀

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

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

SELECT * FROM xx_table WHERE ...

和快照讀相對應(yīng)的另外一個概念叫做當(dāng)前讀，當(dāng)前讀就是讀取最新數(shù)據(jù)，所以，加鎖的 SELECT，或者對數(shù)據(jù)進(jìn)行增刪改都會進(jìn)行當(dāng)前讀，比如：

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實現(xiàn)的基礎(chǔ)，而當(dāng)前讀是悲觀鎖實現(xiàn)的基礎(chǔ)。

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

Undo Log

undo log是Mysql中比較重要的事務(wù)日志之一，顧名思義，undo log是一種用于回退的日志，在事務(wù)沒提交之前，MySQL會先記錄更新前的數(shù)據(jù)到 undo log日志文件里面，當(dāng)事務(wù)回滾時或者數(shù)據(jù)庫崩潰時，可以利用 undo log來進(jìn)行回退。

這里面提到的存在undo log中的”更新前的數(shù)據(jù)”就是我們前面提到的快照。所以，這也是為什么很多人說UndoLog是MVCC實現(xiàn)的重要手段的原因。

那么，一條記錄在同一時刻可能有多個事務(wù)在執(zhí)行，那么，undo log會有一條記錄的多個快照，那么在這一時刻發(fā)生SELECT要進(jìn)行快照讀的時候，要讀哪個快照呢？

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

隱式字段

其實，數(shù)據(jù)庫中的每行記錄中，除了保存了我們自己定義的一些字段以外，還有一些重要的隱式字段的：

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

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

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

有了undo log，又有了幾個隱式字段，我們好像還是不知道具體應(yīng)該讀取哪個快照，那怎么辦呢？

Read View

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

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

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

• trx_ids，系統(tǒng)當(dāng)前未提交的事務(wù) ID 的列表。
• low_limit_id，未提交的事務(wù)中最大的事務(wù) ID。
• up_limit_id，未提交的事務(wù)中最小的事務(wù) ID。
• creator_trx_id，創(chuàng)建這個 Read View 的事務(wù) ID。

每開啟一個事務(wù)，我們都會從數(shù)據(jù)庫中獲得一個事務(wù) ID，這個事務(wù) ID 是自增長的，通過 ID 大小，我們就可以判斷事務(wù)的時間順序。

那么，一個事務(wù)應(yīng)該看到哪些快照，不應(yīng)該看到哪些快照該如何判斷呢？

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

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

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

那么接下來，數(shù)據(jù)庫會拿這條記錄db_trx_id和Read View進(jìn)行可見性比較。

如果db_trx_id<up_limit_id，則說明，在Read View中所有未提交的事務(wù)創(chuàng)建之前，db_trx_id = 3的這個事務(wù)就已經(jīng)提交了，并且在這期間，并沒有新的事務(wù)提交。所有，這條記錄對當(dāng)前事務(wù)就應(yīng)該是可見的。

如果，db_trx_id>low_limit_id，則說明，db_trx_id = 3的這個事務(wù)是在Read View中所有未提交的事務(wù)創(chuàng)建之后才提交的，也就是說，在當(dāng)前事務(wù)開啟之后，有別的事務(wù)修改了數(shù)據(jù)并作了提交。所以，這個記錄對于當(dāng)前事務(wù)來說應(yīng)該就是不可見的。（不可見怎么辦呢？后面講）

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

如果，db_trx_id在trx_ids列表中，那么表示在當(dāng)前事務(wù)開啟時，并未提交的某個事務(wù)在修改數(shù)據(jù)之后提交了，那么這個記錄對于當(dāng)前事務(wù)來說應(yīng)該是不可見的。

如果，db_trx_id不在trx_ids列表中，那么表示的是在當(dāng)前事務(wù)開啟之前，其他事務(wù)對數(shù)據(jù)進(jìn)行修改并提交了，所有，這條記錄對當(dāng)前事務(wù)就應(yīng)該是可見的。

所以，當(dāng)讀取一條記錄的時候，經(jīng)過以上判斷，發(fā)現(xiàn)記錄對當(dāng)前事務(wù)可見，那么就直接返回就行了。那么如果不可見怎么辦？沒錯，那就需要用到undo log了。

當(dāng)數(shù)據(jù)的事務(wù)ID不符合Read View規(guī)則時候，那就需要從undo log里面獲取數(shù)據(jù)的歷史快照，然后數(shù)據(jù)快照的事務(wù)ID再來和Read View進(jìn)行可見性比較，如果找到一條快照，則返回，找不到則返回空。

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

MVCC和隔離級別

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

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

參考資料：

• https://dev.mysql.com/doc/refman/5.7/en/innodb-undo-logs.html
• https://time.geekbang.org/column/article/120351
• https://blog.csdn.net/SnailMann/article/details/94724197
• http://www.szyisi.cn/article/641019.html
• https://zhuanlan.zhihu.com/p/52977862