大廠最愛問的MVCC，到底是個啥？

大家好，我是武哥。

MVCC 的實現(xiàn)原理是大廠最愛問的一道面試題。在武哥的讀者群里，小伙伴們討論過好幾次，好友螺哥的這篇萬字文章，娓娓道來，寫得非常明白，推薦給大家！

1. 相關(guān)數(shù)據(jù)庫知識點回顧

1.1 什么是數(shù)據(jù)庫事務(wù)，為什么要有事務(wù)

事務(wù)，由一個有限的數(shù)據(jù)庫操作序列構(gòu)成，這些操作要么全部執(zhí)行,要么全部不執(zhí)行，是一個不可分割的工作單位。

假如A轉(zhuǎn)賬給B 100 元，先從A的賬戶里扣除 100 元，再在 B 的賬戶上加上 100 元。如果扣完A的100元后，還沒來得及給B加上，銀行系統(tǒng)異常了，最后導(dǎo)致A的余額減少了，B的余額卻沒有增加。所以就需要事務(wù)，將A的錢回滾回去，就是這么簡單。

為什么要有事務(wù)呢？ 就是為了保證數(shù)據(jù)的最終一致性。

1.2 事務(wù)包括哪幾個特性？

事務(wù)四個典型特性，即ACID，原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。

• 原子性：事務(wù)作為一個整體被執(zhí)行，包含在其中的對數(shù)據(jù)庫的操作要么全部都執(zhí)行，要么都不執(zhí)行。
• 一致性：指在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)不會被破壞，假如A賬戶給B賬戶轉(zhuǎn)10塊錢，不管成功與否，A和B的總金額是不變的。
• 隔離性：多個事務(wù)并發(fā)訪問時，事務(wù)之間是相互隔離的，一個事務(wù)不應(yīng)該被其他事務(wù)干擾，多個并發(fā)事務(wù)之間要相互隔離。。
• 持久性：表示事務(wù)完成提交后，該事務(wù)對數(shù)據(jù)庫所作的操作更改，將持久地保存在數(shù)據(jù)庫之中。

1.3 事務(wù)并發(fā)存在的問題

事務(wù)并發(fā)會引起臟讀、不可重復(fù)讀、幻讀問題。

1.3.1 臟讀

如果一個事務(wù)讀取到了另一個未提交事務(wù)修改過的數(shù)據(jù)，我們就稱發(fā)生了臟讀現(xiàn)象。

假設(shè)現(xiàn)在有兩個事務(wù)A、B：

• 假設(shè)現(xiàn)在A的余額是100，事務(wù)A正在準備查詢Jay的余額
• 事務(wù)B先扣減Jay的余額，扣了10，但是還沒提交
• 最后A讀到的余額是90，即扣減后的余額

因為事務(wù)A讀取到事務(wù)B未提交的數(shù)據(jù),這就是臟讀。

1.3.2 不可重復(fù)讀

同一個事務(wù)內(nèi)，前后多次讀取，讀取到的數(shù)據(jù)內(nèi)容不一致

假設(shè)現(xiàn)在有兩個事務(wù)A和B：

• 事務(wù)A先查詢Jay的余額，查到結(jié)果是100
• 這時候事務(wù)B 對Jay的賬戶余額進行扣減，扣去10后，提交事務(wù)
• 事務(wù)A再去查詢Jay的賬戶余額發(fā)現(xiàn)變成了90

事務(wù)A被事務(wù)B干擾到了！在事務(wù)A范圍內(nèi)，兩個相同的查詢，讀取同一條記錄，卻返回了不同的數(shù)據(jù)，這就是不可重復(fù)讀。

1.3.3 幻讀

如果一個事務(wù)先根據(jù)某些搜索條件查詢出一些記錄，在該事務(wù)未提交時，另一個事務(wù)寫入了一些符合那些搜索條件的記錄（如insert、delete、update），就意味著發(fā)生了幻讀。

假設(shè)現(xiàn)在有兩個事務(wù)A、B：

• 事務(wù)A先查詢id大于2的賬戶記錄，得到記錄id=2和id=3的兩條記錄
• 這時候，事務(wù)B開啟，插入一條id=4的記錄，并且提交了
• 事務(wù)A再去執(zhí)行相同的查詢，卻得到了id=2,3,4的3條記錄了。

事務(wù)A查詢一個范圍的結(jié)果集，另一個并發(fā)事務(wù)B往這個范圍中插入新的數(shù)據(jù)，并提交事務(wù)，然后事務(wù)A再次查詢相同的范圍，兩次讀取到的結(jié)果集卻不一樣了，這就是幻讀。

1.4 四大隔離級別

為了解決并發(fā)事務(wù)存在的臟讀、不可重復(fù)讀、幻讀等問題，數(shù)據(jù)庫大叔設(shè)計了四種隔離級別。分別是讀未提交，讀已提交，可重復(fù)讀，串行化（Serializable）。

1.4.1 讀未提交

讀未提交隔離級別，只限制了兩個數(shù)據(jù)不能同時修改，但是修改數(shù)據(jù)的時候，即使事務(wù)未提交，都是可以被別的事務(wù)讀取到的，這級別的事務(wù)隔離有臟讀、重復(fù)讀、幻讀的問題；

1.4.2 讀已提交

讀已提交隔離級別，當(dāng)前事務(wù)只能讀取到其他事務(wù)提交的數(shù)據(jù)，所以這種事務(wù)的隔離級別解決了臟讀問題，但還是會存在重復(fù)讀、幻讀問題；

1.4 3 可重復(fù)讀

可重復(fù)讀隔離級別，限制了讀取數(shù)據(jù)的時候，不可以進行修改，所以解決了重復(fù)讀的問題，但是讀取范圍數(shù)據(jù)的時候，是可以插入數(shù)據(jù)，所以還會存在幻讀問題；

1.4.4 串行化

事務(wù)最高的隔離級別，在該級別下，所有事務(wù)都是進行串行化順序執(zhí)行的。可以避免臟讀、不可重復(fù)讀與幻讀所有并發(fā)問題。但是這種事務(wù)隔離級別下，事務(wù)執(zhí)行很耗性能。

1.4.5 四大隔離級別，都會存在哪些并發(fā)問題呢

1.5 數(shù)據(jù)庫是如何保證事務(wù)的隔離性的呢？

數(shù)據(jù)庫是通過加鎖，來實現(xiàn)事務(wù)的隔離性的。這就好像，如果你想一個人靜靜，不被別人打擾，你就可以在房門上加上一把鎖。

加鎖確實好使，可以保證隔離性。比如串行化隔離級別就是加鎖實現(xiàn)的。但是頻繁的加鎖，導(dǎo)致讀數(shù)據(jù)時，沒辦法修改，修改數(shù)據(jù)時，沒辦法讀取，大大降低了數(shù)據(jù)庫性能。

那么，如何解決加鎖后的性能問題的？

答案就是,MVCC多版本并發(fā)控制！它實現(xiàn)讀取數(shù)據(jù)不用加鎖，可以讓讀取數(shù)據(jù)同時修改。修改數(shù)據(jù)時同時可讀取。

2. 什么是 MVCC？

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

通俗的講，數(shù)據(jù)庫中同時存在多個版本的數(shù)據(jù)，并不是整個數(shù)據(jù)庫的多個版本，而是某一條記錄的多個版本同時存在，在某個事務(wù)對其進行操作的時候，需要查看這一條記錄的隱藏列事務(wù)版本id，比對事務(wù)id并根據(jù)事物隔離級別去判斷讀取哪個版本的數(shù)據(jù)。

數(shù)據(jù)庫隔離級別讀已提交、可重復(fù)讀 都是基于MVCC實現(xiàn)的，相對于加鎖簡單粗暴的方式，它用更好的方式去處理讀寫沖突，能有效提高數(shù)據(jù)庫并發(fā)性能。

3. MVCC實現(xiàn)的關(guān)鍵知識點

3.1 事務(wù)版本號

事務(wù)每次開啟前，都會從數(shù)據(jù)庫獲得一個自增長的事務(wù)ID，可以從事務(wù)ID判斷事務(wù)的執(zhí)行先后順序。這就是事務(wù)版本號。

3.2 隱式字段

對于InnoDB存儲引擎，每一行記錄都有兩個隱藏列trx_id、roll_pointer，如果表中沒有主鍵和非NULL唯一鍵時，則還會有第三個隱藏的主鍵列row_id。

3.3 undo log

undo log，回滾日志，用于記錄數(shù)據(jù)被修改前的信息。在表記錄修改之前，會先把數(shù)據(jù)拷貝到undo log里，如果事務(wù)回滾，即可以通過undo log來還原數(shù)據(jù)。

可以這樣認為，當(dāng)delete一條記錄時，undo log 中會記錄一條對應(yīng)的insert記錄，當(dāng)update一條記錄時，它記錄一條對應(yīng)相反的update記錄。

undo log有什么用途呢？

1. 事務(wù)回滾時，保證原子性和一致性。
2. 用于MVCC快照讀。

3.4 版本鏈

多個事務(wù)并行操作某一行數(shù)據(jù)時，不同事務(wù)對該行數(shù)據(jù)的修改會產(chǎn)生多個版本，然后通過回滾指針（roll_pointer），連成一個鏈表，這個鏈表就稱為版本鏈。如下：

其實，通過版本鏈，我們就可以看出事務(wù)版本號、表格隱藏的列和undo log它們之間的關(guān)系。我們再來小分析一下。

1. 假設(shè)現(xiàn)在有一張core_user表，表里面有一條數(shù)據(jù),id為1，名字為孫權(quán)：

2. 現(xiàn)在開啟一個事務(wù)A：對core_user表執(zhí)行update core_user set name ="曹操" where id=1,會進行如下流程操作

• 首先獲得一個事務(wù)ID=100
• 把core_user表修改前的數(shù)據(jù),拷貝到undo log
• 修改core_user表中，id=1的數(shù)據(jù)，名字改為曹操
• 把修改后的數(shù)據(jù)事務(wù)Id=101改成當(dāng)前事務(wù)版本號，并把roll_pointer指向undo log數(shù)據(jù)地址。

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

快照讀： 讀取的是記錄數(shù)據(jù)的可見版本（有舊的版本）。不加鎖,普通的select語句都是快照讀,如：

select?*?from?core_user?where?id?>?2;

當(dāng)前讀：讀取的是記錄數(shù)據(jù)的最新版本，顯式加鎖的都是當(dāng)前讀

select?*?from?core_user?where?id?>?2?for?update;
select?*?from?account?where?id>2?lock?in?share?mode;

3.6 Read View

• Read View是什么呢？ 它就是事務(wù)執(zhí)行SQL語句時，產(chǎn)生的讀視圖。實際上在innodb中，每個SQL語句執(zhí)行前都會得到一個Read View。
• Read View有什么用呢？ 它主要是用來做可見性判斷的，即判斷當(dāng)前事務(wù)可見哪個版本的數(shù)據(jù)~

Read View是如何保證可見性判斷的呢？我們先看看Read view 的幾個重要屬性

• m_ids:當(dāng)前系統(tǒng)中那些活躍(未提交)的讀寫事務(wù)ID, 它數(shù)據(jù)結(jié)構(gòu)為一個List。
• min_limit_id:表示在生成Read View時，當(dāng)前系統(tǒng)中活躍的讀寫事務(wù)中最小的事務(wù)id，即m_ids中的最小值。
• max_limit_id:表示生成Read View時，系統(tǒng)中應(yīng)該分配給下一個事務(wù)的id值。
• creator_trx_id: 創(chuàng)建當(dāng)前Read?View的事務(wù)ID

Read view 匹配條件規(guī)則如下：

1. 如果數(shù)據(jù)事務(wù)ID trx_id < min_limit_id，表明生成該版本的事務(wù)在生成Read View前，已經(jīng)提交(因為事務(wù)ID是遞增的)，所以該版本可以被當(dāng)前事務(wù)訪問。
2. 如果trx_id>= max_limit_id，表明生成該版本的事務(wù)在生成ReadView后才生成，所以該版本不可以被當(dāng)前事務(wù)訪問。
3. 如果 min_limit_id =,需腰分3種情況討論

• （1）.如果m_ids包含trx_id,則代表Read View生成時刻，這個事務(wù)還未提交，但是如果數(shù)據(jù)的trx_id等于creator_trx_id的話，表明數(shù)據(jù)是自己生成的，因此是可見的。
• （2）如果m_ids包含trx_id，并且trx_id不等于creator_trx_id，則Read ? View生成時，事務(wù)未提交，并且不是自己生產(chǎn)的，所以當(dāng)前事務(wù)也是看不見的；
• （3）.如果m_ids不包含trx_id，則說明你這個事務(wù)在Read View生成之前就已經(jīng)提交了，修改的結(jié)果，當(dāng)前事務(wù)是能看見的。

4. MVCC實現(xiàn)原理分析

4.1 查詢一條記錄，基于MVCC，是怎樣的流程

1. 獲取事務(wù)自己的版本號，即事務(wù)ID
2. 獲取Read View
3. 查詢得到的數(shù)據(jù)，然后Read View中的事務(wù)版本號進行比較。
4. 如果不符合Read View的可見性規(guī)則， 即就需要Undo log中歷史快照;
5. 最后返回符合規(guī)則的數(shù)據(jù)

InnoDB 實現(xiàn)MVCC，是通過Read View+ Undo Log 實現(xiàn)的，Undo Log 保存了歷史快照，Read View可見性規(guī)則幫助判斷當(dāng)前版本的數(shù)據(jù)是否可見。

4.2 讀已提交（RC）隔離級別，存在不可重復(fù)讀問題的分析歷程

1. 創(chuàng)建core_user表，插入一條初始化數(shù)據(jù),如下：

2. 隔離級別設(shè)置為讀已提交（RC），事務(wù)A和事務(wù)B同時對core_user表進行查詢和修改操作。

事務(wù)A:?select?*?fom?core_user?where?id=1
事務(wù)B:?update?core_user?set?name?=”曹操”

執(zhí)行流程如下：

最后事務(wù)A查詢到的結(jié)果是，name=曹操的記錄，我們基于MVCC，來分析一下執(zhí)行流程：

(1). A開啟事務(wù)，首先得到一個事務(wù)ID為100

(2).B開啟事務(wù)，得到事務(wù)ID為101

(3).事務(wù)A生成一個Read View，read view對應(yīng)的值如下

然后回到版本鏈：開始從版本鏈中挑選可見的記錄：

由圖可以看出，最新版本的列name的內(nèi)容是孫權(quán)，該版本的trx_id值為100。開始執(zhí)行read view可見性規(guī)則校驗：

min_limit_id(100)=creator_trx_id?=?trx_id?=100;

由此可得，trx_id=100的這個記錄，當(dāng)前事務(wù)是可見的。所以查到是name為孫權(quán)的記錄。

（4). 事務(wù)B進行修改操作，把名字改為曹操。把原數(shù)據(jù)拷貝到undo log,然后對數(shù)據(jù)進行修改，標記事務(wù)ID和上一個數(shù)據(jù)版本在undo log的地址。

(5) 提交事務(wù)

(6) 事務(wù)A再次執(zhí)行查詢操作，新生成一個Read View，Read View對應(yīng)的值如下

然后再次回到版本鏈：從版本鏈中挑選可見的記錄：

從圖可得，最新版本的列name的內(nèi)容是曹操，該版本的trx_id值為101。開始執(zhí)行Read View可見性規(guī)則校驗：

min_limit_id(100)=但是,trx_id=101，不屬于m_ids集合

因此，trx_id=101這個記錄，對于當(dāng)前事務(wù)是可見的。所以SQL查詢到的是name為曹操的記錄。

綜上所述，在讀已提交（RC）隔離級別下，同一個事務(wù)里，兩個相同的查詢，讀取同一條記錄（id=1），卻返回了不同的數(shù)據(jù)（第一次查出來是孫權(quán)，第二次查出來是曹操那條記錄），因此RC隔離級別，存在不可重復(fù)讀并發(fā)問題。

4.3 可重復(fù)讀（RR）隔離級別，解決不可重復(fù)讀問題的分析

在RR隔離級別下，是如何解決不可重復(fù)讀問題的呢？我們一起再來看下，

還是4.2小節(jié)那個流程，還是這個事務(wù)A和事務(wù)B，如下：

4.3.1 不同隔離級別下，Read View的工作方式不同

實際上，各種事務(wù)隔離級別下的Read view工作方式，是不一樣的，RR可以解決不可重復(fù)讀問題，就是跟Read view工作方式有關(guān)。

• 在讀已提交（RC）隔離級別下，同一個事務(wù)里面，每一次查詢都會產(chǎn)生一個新的Read View副本，這樣就可能造成同一個事務(wù)里前后讀取數(shù)據(jù)可能不一致的問題（不可重復(fù)讀并發(fā)問題）。

• 在可重復(fù)讀（RR）隔離級別下，一個事務(wù)里只會獲取一次read view，都是副本共用的，從而保證每次查詢的數(shù)據(jù)都是一樣的。

4.3.2 實例分析

我們穿越下，回到剛4.2的例子，然后執(zhí)行第2個查詢的時候：

事務(wù)A再次執(zhí)行查詢操作，復(fù)用老的Read View副本，Read View對應(yīng)的值如下

然后再次回到版本鏈：從版本鏈中挑選可見的記錄：

從圖可得，最新版本的列name的內(nèi)容是曹操，該版本的trx_id值為101。開始執(zhí)行read view可見性規(guī)則校驗：

min_limit_id(100)=因為m_ids{100,101}包含trx_id（101），
并且creator_trx_id?(100)?不等于trx_id（101）

所以，trx_id=101這個記錄，對于當(dāng)前事務(wù)是不可見的。這時候呢，版本鏈roll_pointer跳到下一個版本，trx_id=100這個記錄，再次校驗是否可見：

min_limit_id(100)=因為m_ids{100,101}包含trx_id（100），
并且creator_trx_id?(100)?等于trx_id（100）

所以，trx_id=100這個記錄，對于當(dāng)前事務(wù)是可見的，所以兩次查詢結(jié)果，都是name=孫權(quán)的那個記錄。即在可重復(fù)讀（RR）隔離級別下，復(fù)用老的Read View副本，解決了不可重復(fù)讀的問題。

4.4 網(wǎng)絡(luò)江湖傳說，MVCC是否解決了幻讀問題呢？

網(wǎng)絡(luò)江湖有個傳說，說MVCC的RR隔離級別，解決了幻讀問題，我們來一起分析一下。

4.4.1 RR級別下，一個快照讀的例子，不存在幻讀問題

由圖可得，步驟2和步驟6查詢結(jié)果集沒有變化，看起來RR級別是已經(jīng)解決幻讀問題啦~

4.4.2 RR級別下，一個當(dāng)前讀的例子

假設(shè)現(xiàn)在有個account表，表中有4條數(shù)據(jù)，RR級別。

• 開啟事務(wù)A，執(zhí)行當(dāng)前讀，查詢id>2的所有記錄。
• 再開啟事務(wù)B，插入id=5的一條數(shù)據(jù)。

流程如下：

顯然，事務(wù)B執(zhí)行插入操作時，阻塞了~因為事務(wù)A在執(zhí)行select ... lock in share mode（當(dāng)前讀）的時候，不僅在id = 3,4 這2條記錄上加了鎖，而且在id > 2這個范圍上也加了間隙鎖。

因此，我們可以發(fā)現(xiàn)，RR隔離級別下，加鎖的select, update, delete等語句，會使用間隙鎖+ 臨鍵鎖，鎖住索引記錄之間的范圍，避免范圍間插入記錄，以避免產(chǎn)生幻影行記錄，那就是說RR隔離級別解決了幻讀問題？

4.4.3 這種特殊場景，似乎有幻讀問題

其實，上圖事務(wù)A中，多加了update account set balance=200 where id=5;這步操作，同一個事務(wù)，相同的sql，查出的結(jié)果集不同了，這個結(jié)果，就符合了幻讀的定義~

這個問題，親愛的朋友，你覺得它算幻讀問題嗎，所以RR隔離級別，還是存在幻讀問題吧？歡迎大家評論區(qū)留言哈。