MySQL 多版本并發

一、多版本并發控制

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

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

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

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

1、一致性讀

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

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

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

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

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

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

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

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

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

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

2、深入一致性讀原理

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

InnoDB 內實現 MVCC 的關鍵其實就是三個字段，并且數據表中每一行都有這三個字段：

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

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

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

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

二、Undo Log 的組成

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

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

• Insert Undo Log
• Update Undo Log

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

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

對，但也不完全對。

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

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