MySQL 多版本并發(fā)

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

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

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

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

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

1、一致性讀

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

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

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

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

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

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

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

（1）使用讀已提交隔離級(jí)別
（2）對(duì) SELECT 加鎖，共享鎖和排他鎖都行，再具體點(diǎn)就是 FOR SHARE 和 FOR UPDATE
當(dāng)然，第二種方法如果對(duì)應(yīng)的記錄加的鎖和 SELECT 加的鎖互斥，SELECT 就會(huì)被阻塞，這種讀也有個(gè)別名叫 當(dāng)前讀。

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

但是我覺(jué)得還不夠，應(yīng)該還需要繼續(xù)往下深入了解。因?yàn)槲覀冎恢纻€(gè)快照，其底層到底是怎么實(shí)現(xiàn)的呢？其實(shí)還是不知道的。

2、深入一致性讀原理

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

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

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

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

可能有人對(duì) Undo Log 沒(méi)啥概念，記住這個(gè)就好了：

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

二、Undo Log 的組成

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

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

• Insert Undo Log
• Update Undo Log

對(duì)于 Insert Undo Log 來(lái)說(shuō)，它只會(huì)用于在事務(wù)中發(fā)生錯(cuò)誤的回滾，因?yàn)橐坏┦聞?wù)提交了，Insert Undo Log 就完全沒(méi)用了，所以在事務(wù)提交之后 Insert Undo Log 就會(huì)被刪除。

而 Update Undo Log 不同，其可以用于 MVCC 的一致性讀，為不同版本的請(qǐng)求提供數(shù)據(jù)源。那這樣一來(lái)，是不是 Update Undo Log 就完全沒(méi)法移除了？因?yàn)槟悴磺宄稌r(shí)候就會(huì)有個(gè)一致性讀請(qǐng)求過(guò)來(lái)，然后導(dǎo)致其占用的空間越來(lái)越大。

對(duì)，但也不完全對(duì)。

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

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