[[414680]]

之前的文章簡單的介紹了 MySQL 的事務(wù)隔離級別，它們分別是：讀未提交、讀已提交、可重復(fù)讀、串行化。這篇文章我們就來探索一下 MySQL 事務(wù)隔離級別的底層原理。

本篇文章針對 InnoDB 存儲引擎

多版本并發(fā)控制

我們知道，讀未提交會造成臟讀、幻讀、不可重復(fù)讀，讀已提交會造成幻讀、不可重復(fù)讀，可重復(fù)讀可能會有幻讀，和串行化就不會有這些問題。

那 InnoDB 到底是怎么解決這些問題的呢?又或者，你有沒有想過造成臟讀、幻讀、不可重復(fù)讀的底層最根本的原因是什么呢?

這就是今天要聊的主角——MVCC(Multi-Version Concurrent Controll)，也叫多版本并發(fā)控制。InnoDB 是一個支持多事務(wù)并發(fā)的存儲引擎，它能讓數(shù)據(jù)庫中的讀-寫操作能夠并發(fā)的進(jìn)行，避免由于加鎖而導(dǎo)致讀阻塞。

正是由于有了 MVCC，在事務(wù)B更新 id=1 的數(shù)據(jù)時，事務(wù)A讀取 id=1 的操作才不會被阻塞。而不阻塞的背后則是不加鎖的一致性讀。那什么是一致性讀?

一致性讀

簡單來講，當(dāng)進(jìn)行 query 查詢時，InnoDB 會對當(dāng)前時間點的數(shù)據(jù)庫創(chuàng)建一個快照，快照創(chuàng)建完之后，當(dāng)前查詢就只能感知到快照創(chuàng)建之前提交的事務(wù)改動，在快照創(chuàng)建之后再提交的事務(wù)就不會被當(dāng)前query感知。

當(dāng)然，當(dāng)前事務(wù)自己更新的數(shù)據(jù)是個例外。當(dāng)前事務(wù)修改過的行，再次讀取時是能夠拿到最新的數(shù)據(jù)的。而對于其他行，讀取的仍然是打快照時的版本。

而這個快照就是 InnoDB 實現(xiàn)事務(wù)隔離級別的關(guān)鍵。

在讀已提交(Read Committed)的隔離級別下，事務(wù)中的每一次的一致性讀都會重新生成快照。而在可重復(fù)讀(Repeatable Read)的隔離級別下，事務(wù)中所有的一致性讀都只會使用第一次一致性讀生成的快照。

這也就是為什么，在上圖中事務(wù)B提交了事務(wù)之后，讀已提交的隔離級別下能看到改動，可重復(fù)讀的隔離級別看不到改動，本質(zhì)上就是因為讀已提交又重新生成了快照。

在讀已提交、可重復(fù)讀的隔離級別下，SELECT 語句都會默認(rèn)走一致性讀，并且在一致性讀的場景下，不會加任何的鎖。其他的修改操作也可以同步的進(jìn)行，大大的提升了 MySQL 的性能。而這也就是MVCC多版本并發(fā)控制的實現(xiàn)原理。這種讀還有個名字叫 快照讀 。

那如果我在事務(wù)中想要立馬看到其他的事務(wù)的提交怎么辦?有兩種方法：

使用讀已提交隔離級別

對 SELECT 加鎖，共享鎖和排他鎖都行，再具體點就是 FOR SHARE 和 FOR UPDATE

當(dāng)然，第二種方法如果對應(yīng)的記錄加的鎖和 SELECT 加的鎖互斥，SELECT 就會被阻塞，這種讀也有個別名叫 當(dāng)前讀。

了解完上面的解釋，下次再有人問你 MVCC 是怎么實現(xiàn)的，你就能從一致性讀(快照讀)和當(dāng)前讀來進(jìn)行解釋了，并且把不同的隔離級別下對一致性讀快照的刷新機制也講清楚。

但是我覺得還不夠，應(yīng)該還需要繼續(xù)往下深入了解。因為我們只知道個快照，其底層到底是怎么實現(xiàn)的呢?其實還是不知道的。

深入一致性讀原理

從常理來說，不同的一致性讀可能會讀到不同版本的數(shù)據(jù)，那么這些肯定都存儲在 MySQL 中的，否則不可能被讀取到。是的，這些數(shù)據(jù)都存儲在 InnoDB 的表空間內(nèi)，再具體點這些數(shù)據(jù)存儲在 Undo 表空間內(nèi)。

InnoDB 內(nèi)實現(xiàn) MVCC 的關(guān)鍵其實就是三個字段，并且數(shù)據(jù)表中每一行都有這三個字段：

• DB_TRX_ID 該字段有6個字節(jié)，用于存儲上次插入或者更新該行數(shù)據(jù)的事務(wù)的唯一標(biāo)識。你可能會問，只有插入和更新嗎?那刪除呢?其實在InnoDB的內(nèi)部，刪除其實就是更新操作，只不過會更新該行中一個特定的比標(biāo)志位，將其標(biāo)記為刪除。
• DB_ROLL_PTR 該字段有7個字節(jié)，你可以叫它回滾指針，該指針指向了存儲在回滾段中的一條具體的Undo Log。即使當(dāng)前這行數(shù)據(jù)被更新了，我們同樣的可以通過回滾指針，拿到更新之前的歷史版本數(shù)據(jù)。
• DB_ROW_ID 該字段有6個字節(jié)，InnoDB給該行數(shù)據(jù)的唯一標(biāo)識，該唯一標(biāo)識會在有新數(shù)據(jù)插入的時候單調(diào)遞增，就跟我們平時定義表結(jié)構(gòu)的時候定義的primary key的時候單調(diào)遞增是一樣的。DB_ROW_ID會被包含在聚簇索引中，其他的非聚簇索引則不會包含。

通過 DB_ROLL_PTR 可以拿到最新的一條 Undo Log，然后每一個對應(yīng)的 Undo Log 指向其上一個 Undo Log，這樣一來，不同的版本就可以連接起來形成鏈表，不同的事務(wù)根據(jù)需求和規(guī)則，從鏈表中選擇不同的版本進(jìn)行讀取，從而實現(xiàn)多版本的并發(fā)控制，就像這樣：

可能有人對 Undo Log 沒啥概念，記住這個就好了：

Undo Log 記錄的是此次事務(wù)開始前的數(shù)據(jù)狀態(tài)，就有點類似于 Git 中的某個 commit，你提交了某個 commit， 然后開始做一個及其復(fù)雜的需求，然后做著做著心態(tài)就崩了，就不想要這些改動了，你就可以直接 git reset --hard $last_commit_id 回退，上個 commit 你就可以理解為 Undo Log，感興趣的可以去看看 基于Redo Log和Undo Log的MySQL崩潰恢復(fù)流程

Undo Log 的組成

可能也有人會有疑問，說 Undo Log 不是應(yīng)該在事務(wù)提交之后就被刪除了嗎?為什么我通過 MVCC 還能查到之前的數(shù)據(jù)呢?

實際上在 InnoDB 中，Undo Log 被分成了兩部分，分別是

• Insert Undo Log
• Update Undo Log

對于 Insert Undo Log 來說，它只會用于在事務(wù)中發(fā)生錯誤的回滾，因為一旦事務(wù)提交了，Insert Undo Log 就完全沒用了，所以在事務(wù)提交之后 Insert Undo Log 就會被刪除。

而 Update Undo Log 不同，其可以用于 MVCC 的一致性讀，為不同版本的請求提供數(shù)據(jù)源。那這樣一來，是不是 Update Undo Log 就完全沒法移除了?因為你不清楚啥時候就會有個一致性讀請求過來，然后導(dǎo)致其占用的空間越來越大。

對，但也不完全對。

一致性讀本質(zhì)上是要處理多事務(wù)并發(fā)時，需要按需給不同的事務(wù)以不同的數(shù)據(jù)版本，所以如果當(dāng)前沒有事務(wù)存在了，Update Undo Log 就可以被干掉了。

MySQL 的官方建議有點皮，建議大家定期提交事務(wù)，這樣機器上的 Undo Logs 就可以被定期的清理。我尋思，不提交事務(wù)整個 DB 不就 hang 住了，那不完犢子了嗎..

EOF

本篇文章就先到這里，至于怎么 Update Undo Log 怎么被干掉的，之后有空專門寫篇文章來聊聊。