MySQL 到底是如何做到多版本并發(fā)的

MySQL 多版本并發(fā)

一、多版本并發(fā)控制

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

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

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

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

1、一致性讀

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

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

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

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

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

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

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

（1）使用讀已提交隔離級別
（2）對 SELECT 加鎖，共享鎖和排他鎖都行，再具體點就是 FOR SHARE 和 FOR UPDATE
當然，第二種方法如果對應的記錄加的鎖和 SELECT 加的鎖互斥，SELECT 就會被阻塞，這種讀也有個別名叫 當前讀。

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

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

2、深入一致性讀原理

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

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

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

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

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

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

二、Undo Log 的組成

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

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

• Insert Undo Log
• Update Undo Log

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

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

對，但也不完全對。

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

到此這篇關于MySQL 到底是如何做到多版本并發(fā)的？的文章就介紹到這了,更多相關MySQL多版本并發(fā)內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！