【51CTO.com原創(chuàng)稿件】都知道事務(wù)的可重復(fù)讀級別實(shí)現(xiàn)原理是使用 MVCC 實(shí)現(xiàn)的，那么你對 MVCC 的底層實(shí)現(xiàn)原理知道多少呢!面試高頻點(diǎn)，你值得擁有。

[[391281]]

圖片來自 Pexels

MVCC 到底是什么?

MVCC 即多版本控制器，其特點(diǎn)就是在同一時(shí)間，不同事務(wù)可以讀取到不同版本的數(shù)據(jù)，從而去解決臟讀和不可重復(fù)讀的問題。

[[391282]]

這樣的解釋你看了不下幾十遍了吧!但是你真的理解什么是多版本控制器嗎?

①生活案例：搬家

最近小 Q 跟自己的女朋友需要搬到新家，由于出小區(qū)的的時(shí)候需要支付當(dāng)月的物業(yè)費(fèi)。于是小 Q 跟自己的女朋友同時(shí)登陸了小區(qū)提供的物業(yè)繳費(fèi)系統(tǒng)。

②悲觀并發(fā)控制

假設(shè)小 Q 正在查當(dāng)月需要繳納的費(fèi)用是多少，然后進(jìn)行支付的時(shí)候，此時(shí)小 Q 查詢的這條數(shù)據(jù)是已經(jīng)被鎖定的。

那么小 Q 女朋友是無法訪問該數(shù)據(jù)的，直至小 Q 支付完成或者退出系統(tǒng)將悲觀鎖釋放，小 Q 的女朋友才可以查詢到數(shù)據(jù)。

悲觀鎖保證在同一時(shí)間只能有一個(gè)線程訪問，默認(rèn)數(shù)據(jù)在訪問的時(shí)候會(huì)產(chǎn)生沖突，然后在整個(gè)過程都加上了鎖。

這樣的系統(tǒng)對于站在程序員的角度看就是毫無用戶體驗(yàn)感，如果多個(gè)人需要同時(shí)訪問一條信息，只能在一臺設(shè)備上看嘍!

③樂觀并發(fā)控制

在小 Q 查看物業(yè)費(fèi)欠費(fèi)情況，并且支付的同時(shí)，小 Q 的女朋友也可以訪問到該數(shù)據(jù)。

樂觀鎖認(rèn)為即使在并發(fā)環(huán)境下，也不會(huì)產(chǎn)生沖突問題，所以不會(huì)去做加鎖操作。而是在數(shù)據(jù)提交的時(shí)候進(jìn)行檢測，如果發(fā)現(xiàn)有沖突則返回沖突信息。

小結(jié)：Innodb 的 MVCC 機(jī)制就是樂觀鎖的一種體現(xiàn)，讀不加鎖，讀寫不沖突，在不加鎖的情況下能讓多個(gè)事務(wù)進(jìn)行并發(fā)讀寫，并且解決讀寫沖突問題，極大的提高系統(tǒng)的并發(fā)性。

悲觀鎖、樂觀鎖

鎖按照粒度分為表鎖、行鎖、頁鎖;按照使用方式分為共享鎖、排它鎖;根據(jù)思想分為樂觀鎖、悲觀鎖。

無論是樂觀鎖、悲觀鎖都只是一種思想而已，并不是實(shí)際的鎖機(jī)制，這點(diǎn)一定要清楚。

①悲觀鎖(悲觀并發(fā)控制)

悲觀鎖實(shí)際為悲觀并發(fā)控制，縮寫 PCC。

悲觀鎖持消極態(tài)度，認(rèn)為每一次訪問數(shù)據(jù)時(shí)，總是會(huì)發(fā)生沖突，因此，每次訪問必須先鎖住數(shù)據(jù)，完成訪問后在釋放鎖。

保證在同一時(shí)間只有單個(gè)線程可以訪問，實(shí)現(xiàn)數(shù)據(jù)的排它性。同時(shí)悲觀鎖使用數(shù)據(jù)庫自身的鎖機(jī)制實(shí)現(xiàn)，可以解決讀-寫，寫-寫的沖突。

那么在什么場景下可以使用悲觀鎖呢?悲觀鎖適用于在寫多讀少的并發(fā)環(huán)境下使用，雖然并發(fā)效率不高，但是保證了數(shù)據(jù)的安全性。

②樂觀鎖(樂觀并發(fā)控制)

跟悲觀鎖一樣，樂觀鎖實(shí)際為樂觀并發(fā)控制，縮寫為OCC。

樂觀鎖相對于悲觀鎖而言，認(rèn)為即使在并發(fā)環(huán)境下，外界對數(shù)據(jù)的操作不會(huì)產(chǎn)生沖突，所以不會(huì)去加鎖，而是會(huì)在提交更新的時(shí)候才會(huì)正式的對數(shù)據(jù)的沖突與否進(jìn)行檢測。

如果發(fā)現(xiàn)沖突，要么再重試一次，要么切換為悲觀的策略。樂觀并發(fā)控制要解決的是數(shù)據(jù)庫并發(fā)場景下的寫-寫沖突，指用無鎖的方式去解決。

MVCC 解決了哪些問題

在事務(wù)并發(fā)的情況下會(huì)產(chǎn)生以下問題：

• 臟讀：讀取其他事務(wù)未提交的數(shù)據(jù)。
• 不可重復(fù)讀：一個(gè)事務(wù)在讀取一條數(shù)據(jù)時(shí)，由于另一個(gè)事務(wù)修改了這條數(shù)據(jù)，導(dǎo)致前后讀取的數(shù)據(jù)不一致。
• 幻讀：一個(gè)事務(wù)先讀取了某個(gè)范圍的數(shù)量，同時(shí)另一個(gè)事務(wù)新增了這個(gè)范圍的數(shù)據(jù)，再次讀取發(fā)現(xiàn)倆次得到的結(jié)果不一致。

MVCC 在 Innodb 存儲引擎的實(shí)現(xiàn)主要是為了提高數(shù)據(jù)庫并發(fā)能力，用更好的方式去處理讀–寫沖突，同時(shí)做到不加鎖、非阻塞并發(fā)讀寫。

但是 MVCC 可以解決臟讀，不可重復(fù)讀，MVCC 使用快照讀解決了部分幻讀問題，但是在修改時(shí)還是使用的當(dāng)前讀，所以還是存在幻讀問題，幻讀的問題最終就是使用間隙鎖解決。

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

在了解 MVCC 是如何解決事務(wù)并發(fā)帶來的問題之前，需要先明白倆個(gè)概念，當(dāng)前讀、快照讀。

①當(dāng)前讀

給讀操作加上共享鎖、排它鎖，DML 操作加上排它鎖，這些操作就是當(dāng)前讀。

共享鎖、排它鎖也被稱之為讀鎖、寫鎖。共享鎖與共享鎖是共存的，但是如果要修改、添加、刪除時(shí)，必須等到共享鎖釋放才可進(jìn)行操作。

因?yàn)樵?Innodb 存儲引擎中，DML 操作都會(huì)隱式添加排它鎖。所以說當(dāng)前讀所讀取的記錄就是最新的記錄，讀取數(shù)據(jù)時(shí)加上鎖，保證其他事務(wù)不能修改當(dāng)前記錄。

②快照讀

如果你看到這里就默認(rèn)你對隔離級別有一定的了解哈!快照讀的前提是隔離級別不是串行級別，串行級別的快照讀會(huì)退化成當(dāng)前讀。

快照讀的出現(xiàn)旨在提高事務(wù)并發(fā)性，其實(shí)現(xiàn)基于本文的主角 MVCC 即多版本控制器。

MVCC 可以認(rèn)為就是行鎖的一個(gè)變種，但是它在很多情況下避免了加鎖操作。所以說快照讀讀取的數(shù)據(jù)有可能不是最新的，而是之前版本的數(shù)據(jù)。

為什么要提到快照讀呢!因?yàn)樵?read-view 就是通過快照讀生成的，為了防止后文概念模糊，所以在這里進(jìn)行說明。

③如何區(qū)分當(dāng)前讀、快照讀

不加鎖的簡單的 select 都屬于快照讀：

select id name user where id = 1; 

與之對應(yīng)的則是當(dāng)前讀，給 select 加上共享鎖、排它鎖：

select id name from user where id = 1 lock in share mode; 
 
select id name from user where id = 1 for update; 

MVCC 實(shí)現(xiàn)三大要素

終于來到本文最終要的部分了，前邊的敘述都是為了原理這一塊做的鋪墊。

在這之前需要知道 MVCC 只在 REPEATABLE READ(可重復(fù)讀) 和 READ COMMITTED(已讀提交)這倆種隔離級別下適用。

MVCC 實(shí)現(xiàn)原理是由倆個(gè)隱式字段、undo 日志、Read view 來實(shí)現(xiàn)的。

①隱式字段

在 Innodb 存儲引擎中，在有聚簇索引的情況下每一行記錄中都會(huì)隱藏倆個(gè)字段，如果沒有聚簇索引則還有一個(gè) 6byte 的隱藏主鍵。

這倆個(gè)隱藏列一個(gè)記錄的是何時(shí)被創(chuàng)建的，一個(gè)記錄的是什么時(shí)候被刪除。這里不要理解為是記錄的是時(shí)間，存儲的是事務(wù) ID。

倆個(gè)隱式字段為 DB_TRX_ID，DB_ROLL_PTR，沒有聚簇索引還會(huì)有 DB_ROW_ID 這個(gè)字段：

• DB_TRX_ID：記錄創(chuàng)建這條記錄上次修改他的事務(wù) ID。
• DB_ROLL_PTR：回滾指針，指向這條記錄的上一個(gè)版本。

隱式字段實(shí)際還有一個(gè) delete flag 隱藏字段，即記錄被更新或刪除，這里的刪除并不代表真的刪除，而是將這條記錄的 delete flag 改為 true(這里埋下一個(gè)伏筆，數(shù)據(jù)庫的刪除是真的刪除嗎?)

②undo log(回滾日志)

之前對 undo log 的作用只提到了回滾操作實(shí)現(xiàn)原子性，現(xiàn)在需要知道的另一個(gè)作用就是實(shí)現(xiàn) MVCC 多版本控制器。

undo log 細(xì)分為倆種：

• insert 時(shí)產(chǎn)生的 undo log、update
• delete 時(shí)產(chǎn)生的 undo log

在 Innodb 中 insert 產(chǎn)生的 undo log 在提交事務(wù)之后就會(huì)被刪除，因?yàn)樾虏迦氲臄?shù)據(jù)沒有歷史版本，所以無需維護(hù) undo log。

update 和 delete 操作產(chǎn)生的 undo log 都屬于一種類型，在事務(wù)回滾時(shí)需要，而且在快照讀時(shí)也需要，則需要維護(hù)多個(gè)版本信息。

只有在快照讀和事務(wù)回滾不涉及該日志時(shí)，對應(yīng)的日志才會(huì)被 purge 線程統(tǒng)一刪除。

purge 線程會(huì)清理 undo log 的歷史版本，同樣也會(huì)清理 del flag 標(biāo)記的記錄。

寫到這里關(guān)于 undo log 在 MVCC 中的作用估計(jì)還是蒙圈的。

undo log 在 MVCC 中的作用：undo log 保存的是一個(gè)版本鏈，也就是使用 DB_ROLL_PTR 這個(gè)字段來連接的。當(dāng)數(shù)據(jù)庫執(zhí)行一個(gè) select 語句時(shí)會(huì)產(chǎn)生一致性視圖 read view。

那么這個(gè) read view 是由在查詢時(shí)所有未提交事務(wù) ID 組成的數(shù)組，數(shù)組中最小的事務(wù) ID 為 min_id 和已創(chuàng)建的最大事務(wù) ID 為 max_id 組成，查詢的數(shù)據(jù)結(jié)果需要跟 read-view 做比較從而得到快照結(jié)果。

所以說 undo log 在 MVCC 中的作用就是為了根據(jù)存儲的事務(wù) ID 做比較，從而得到快照結(jié)果。

③undo log 底層實(shí)現(xiàn)

假設(shè)一開始的數(shù)據(jù)為下圖：

此時(shí)執(zhí)行了一條更新的 SQL 語句：

update user set name = 'niuniu where id = 1' 

那么 undo log 的記錄就會(huì)發(fā)生變化，也就是說當(dāng)執(zhí)行一條更新語句時(shí)會(huì)把之前的原有數(shù)據(jù)拷貝到 undo log 日志中。

同時(shí)你可以看見最新的一條記錄在末尾處連接了一條線，也就是說 DB_ROLL_PTR 記錄的就是存放在 undo log 日志的指針地址。

最終有可能需要通過指針來找到歷史數(shù)據(jù)：

④read-view

當(dāng)執(zhí)行 SQL 語句查詢時(shí)會(huì)產(chǎn)生一致性視圖，也就是 read-view，它是由查詢的那一時(shí)間所有未提交事務(wù) ID 組成的數(shù)組，和已經(jīng)創(chuàng)建的最大事務(wù) ID 組成的。

在這個(gè)數(shù)組中最小的事務(wù) ID 被稱之為 min_id，最大事務(wù) ID 被稱之為 max_id，查詢的數(shù)據(jù)結(jié)果要根據(jù) read-view 做對比從而得到快照結(jié)果。

于是就產(chǎn)生了以下的對比規(guī)則，這個(gè)規(guī)則就是使用當(dāng)前的記錄的 trx_id 跟 read-view 進(jìn)行對比，對比規(guī)則如下。

⑤版本鏈對比規(guī)則

如果落在 trx_id

如果落在 trx_id>max_id，表示此版本是由將來啟動(dòng)的事務(wù)生成的，是肯定不可見的。

如果落在 min_id<=trx_id<=max_id 會(huì)存在倆種情況：

• 如果 row 的 trx_id 在數(shù)組中，表示此版本是由還沒提交的事務(wù)生成的，不可見，但是當(dāng)前自己的事務(wù)是可見的。
• 如果 row 的 trx_id 不在數(shù)組中，表明是提交的事務(wù)生成了該版本，可見。

在這里還有一個(gè)特殊情況那就是對于已經(jīng)刪除的數(shù)據(jù)，在之前的 undo log 日志講述時(shí)說了 update 和 delete 是同一種類型的 undo log，同樣也可以認(rèn)為 delete 就是 update 的特殊情況。

當(dāng)刪除一條數(shù)據(jù)時(shí)會(huì)將版本鏈上最新的數(shù)據(jù)復(fù)制一份，然后將 trx_id 修改為刪除時(shí)的 trx_id，同時(shí)在該記錄的頭信息中存在一個(gè) delete flag 標(biāo)記，將這個(gè)標(biāo)記寫上 true，用來表示當(dāng)前記錄已經(jīng)刪除。

在查詢時(shí)按照版本鏈的規(guī)則查到對應(yīng)的記錄，如果 delete flag 標(biāo)記位為 true，意味著數(shù)據(jù)已經(jīng)被刪除，則不返回?cái)?shù)據(jù)。

如果你對這里的 read-view 的生成和版本鏈對比規(guī)則不懂，不要著急，也不要在這里浪費(fèi)時(shí)間，請繼續(xù)往下看，我會(huì)使用一個(gè)簡單的案例和一個(gè)復(fù)雜的案例給大家重現(xiàn)上述的規(guī)則。

MVCC 底層原理

案例一

下圖是準(zhǔn)備的素材，這里應(yīng)該都理解 select 返回的結(jié)果為 niuniu，即事務(wù) 102 修改后的結(jié)果：

在上圖中可以看到有三個(gè)事務(wù)在進(jìn)行。事務(wù) ID 為 100、101 是修改的其他表，只有事務(wù) ID 為 102 修改的需要查詢的這張表。

接下來看看 select 這一列查詢返回的結(jié)果是不是就是事務(wù) ID 為 102 修改的結(jié)果。

此時(shí)生成的 read-view 為 [100,101],102，那么現(xiàn)在就可以返回去看一下 read-view 規(guī)則，在這里事務(wù) ID100 就是 min_id，事務(wù) ID102 就是 max_id。

這個(gè) select 語句返回結(jié)果肯定是 niuniu。那么接下來看一下在 MVCC 中是如何查找數(shù)據(jù)的。

當(dāng)前版本鏈：

那么就會(huì)拿著這個(gè) trx_id 為 102 進(jìn)行比對，會(huì)發(fā)現(xiàn)這個(gè) 102 就是 max_id，然后你再看一下版本鏈的對比規(guī)則中第三種情況。

如果落在 min_id<=trx_id<=max_id 會(huì)存在倆種情況。此時(shí)信息就已經(jīng)非常明確了，事務(wù) ID102 是沒有在數(shù)組中的，所以表示這個(gè)版本是已經(jīng)提交的事務(wù)生成的，那么就是可見的唄!

毫無疑問查詢會(huì)返回 niuniu 這個(gè)值，先通過這個(gè)簡單的案例讓你對版本鏈有一個(gè)簡單的理解，接下來將使用一個(gè)比較繁瑣的案例再來跟大家演示一遍。

案例二

本例要求知道 select 的第二次查詢結(jié)果。深黑色字體。同樣是在 kaka 那一條記錄的基礎(chǔ)上。

當(dāng)事務(wù) ID100 倆次更新后，版本鏈也會(huì)改變，此時(shí)的版本鏈如下圖。紅色部分為最新數(shù)據(jù)，藍(lán)色數(shù)據(jù)為 undo log 的版本鏈數(shù)據(jù)。

對于此時(shí)生成的 read-view 你會(huì)有什么疑問，在 RR 級別也就是可重復(fù)讀的隔離級別下。

當(dāng)在一個(gè)事務(wù)下執(zhí)行查詢時(shí)，所有的 read-view 都是沿用的第一條查詢語句生成的。

那此時(shí)的 read-view 也就是[100,101],102。

看一下底層查找步驟：

• 當(dāng)前數(shù)據(jù)的事務(wù) ID 為 100
• 根據(jù)規(guī)則會(huì)落在 min_id<=trx_id<=max_id 這個(gè)區(qū)間
• 并且當(dāng)前行的事務(wù) ID100 是在 read-view 的數(shù)組中的，表示此時(shí)的事務(wù)還沒有提交則不可見
• 繼續(xù)在版本鏈中往下尋找，此時(shí)找到的事務(wù) ID 還是 100，跟上述流程一致
• 通過查找版本鏈，將發(fā)現(xiàn)事務(wù) ID 為 102
• 102 是 read-view 的 max_id，同樣也會(huì)落在 min_id<=trx_id<=max_id 這個(gè)區(qū)間，但是跟之前不同的是，事務(wù) 102 是沒有在數(shù)組中的，表示這個(gè)版本事務(wù)已經(jīng)提交了所以是可見的
• 最后返回的是 niuniu

案例三

為了讓大家體會(huì)一下可重復(fù)讀級別生成的 read-view 是根據(jù)在同一事務(wù)中第一條快照讀產(chǎn)生的，再來看一個(gè)案例。

此時(shí)的事務(wù) ID101 也再對數(shù)據(jù)更新兩次，然后在進(jìn)行查詢看一下會(huì)返回什么值：

經(jīng)過案例一、案例二的熟悉，現(xiàn)在對 undo log 的版本鏈和對比規(guī)則已經(jīng)有了一定的了解了吧!

案例三就不在那么詳細(xì)的說明了，此時(shí)的版本鏈如下：

此時(shí)的 read-view 依然為[100,101],102。

那么首先會(huì)根據(jù)事務(wù) 101 去版本鏈對比，事務(wù) 101 和事務(wù) 100 都會(huì)落在 min_id<=trx_id<=max_id 這個(gè)區(qū)間，并且還都在數(shù)組中，所以數(shù)據(jù)是不可見的。

那么繼續(xù)往版本鏈中尋找就會(huì)到事務(wù) 102，這個(gè)是最大的事務(wù) ID 并且不在數(shù)組中，所以是可見的。

于是最終的返回結(jié)果還是 niuniu。

案例四

可以看到個(gè)案例三的圖不同的是新增了一個(gè)查詢語句，那么假設(shè)這兩條語句執(zhí)行的時(shí)間都是一致的，它們返回的結(jié)果會(huì)相同嗎?

案例三查詢到的值為 niuniu：

其實(shí)現(xiàn)在版本鏈跟案例三也是一致的：

那么來理一下尋找過程：

• 首先這里的 read-view 發(fā)生了變化，此時(shí)的 read-view 為[101],102。
• 拿著當(dāng)前的事務(wù) ID101 跟版本鏈規(guī)則進(jìn)行對比，落盤在 min_id<=trx_id<=max_id，并且在數(shù)組中，則數(shù)據(jù)不可見。
• 然后進(jìn)入版本鏈，找到下一個(gè)數(shù)據(jù)的事務(wù) ID，還是 101，與上一個(gè)一致。
• 接下來是事務(wù) ID100。
• 事務(wù) ID100 是落在 trx_id
• 所以最終返回結(jié)果為 niuniu2。

小結(jié)：在同一個(gè)事務(wù)中進(jìn)行查詢，會(huì)沿用第一次查詢語句生成的 read-view(前提是隔離級別是在可重復(fù)讀)。

通過以上的四個(gè)案例，在版本鏈尋找過程中，可以總結(jié)出一個(gè)小技巧：

根據(jù)這個(gè)小技巧你可以很快的得知此版本是否可見：

• 如果當(dāng)前的事務(wù) ID 在綠色部分，是已經(jīng)提交事務(wù)，則數(shù)據(jù)可見。
• 如果當(dāng)前的事務(wù) ID 在藍(lán)色部分，會(huì)有兩種情況，如果當(dāng)前事務(wù) ID 在 read-view 數(shù)組內(nèi)，是沒有提交的事務(wù)不可見，如果不在數(shù)組內(nèi)數(shù)據(jù)可見。
• 如果落在紅色部分，則不考慮，對于未來的事情不去想即可。

總結(jié)

閱讀本文后，在面試過程中極大可能會(huì)遇到的問題就是聊聊你對 MVCC 的認(rèn)識。

本文內(nèi)容從淺到深，從什么是 MVCC 到 MVCC 的底層實(shí)現(xiàn)，一步一步地陳述了 MVCC 的實(shí)現(xiàn)原理。

本文簡單總結(jié)：

• MVCC 在不加鎖的情況下解決了臟讀、不可重復(fù)讀和快照讀下的幻讀問題，一定不要認(rèn)為幻讀完全是 MVCC 解決的。
• 對當(dāng)前讀、快照讀理解，簡單點(diǎn)說加鎖就是當(dāng)前讀，不加鎖的就是快照讀。
• MVCC 實(shí)現(xiàn)的三大要素：兩個(gè)隱式字段、回滾日志、read-view。
• 兩個(gè)隱式字段：DB_TRX_ID：記錄創(chuàng)建這條記錄最后一次修改該記錄的事務(wù)ID;DB_ROLL_PTR：回滾指針，指向這條記錄的上一個(gè)版本。
• undo log 在更新數(shù)據(jù)時(shí)會(huì)產(chǎn)生版本鏈，是 read-view 獲取數(shù)據(jù)的前提。
• read-view 當(dāng) SQL 執(zhí)行查詢語句時(shí)產(chǎn)生的，是由為提交的事務(wù) ID 組成的數(shù)組和創(chuàng)建的最大事務(wù) ID 組成的。
• 版本鏈規(guī)則看第六節(jié)的小結(jié)即可。

作者：咔咔

編輯：陶家龍

征稿：有投稿、尋求報(bào)道意向技術(shù)人請?zhí)砑有【幬⑿?gordonlonglong

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】