面試官：談談你對Mysql的MVCC的理解?

MVCC(Mutil-Version Concurrency Control)，就是多版本併發控制。MVCC 是一種併發控制的方法，通常在數據庫管理系統中，實現對數據庫的併發訪問。

在Mysql的InnoDB引擎中就是指在已提交讀(READ COMMITTD)和可重複讀(REPEATABLE READ)這兩種隔離級別下的事務對於SELECT操做會訪問版本鏈中的記錄的過程。

這就使得別的事務能夠修改這條記錄，反正每次修改都會在版本鏈中記錄。SELECT能夠去版本鏈中拿記錄，這就實現了讀-寫，寫-讀的併發執行，提高了系統的性能。

咱們來具體看看是如何實現的。

版本鏈

咱們先來理解一下版本鏈的概念。在InnoDB引擎表中，它的聚簇索引記錄中有兩個必要的隱藏列：

• trx_id

這個id用來存儲的每次對某條聚簇索引記錄進行修改的時候的事務id。

• roll_pointer

  每次對哪條聚簇索引記錄有修改的時候，都會把老版本寫入undo日誌中。這個roll_pointer就是存了一個指針，它指向這條聚簇索引記錄的上一個版本的位置，經過它來得到上一個版本的記錄信息。(注意插入操做的undo日誌沒有這個屬性，由於它沒有老版本)

好比如今有個事務id是60的執行的這條記錄的修改語句

此時在undo日誌中就存在版本鏈

ReadView

說了版本鏈咱們再來看看ReadView。已提交讀和可重複讀的區別就在於它們生成ReadView的策略不一樣。

ReadView中主要就是有個列表來存儲咱們系統中當前活躍着的讀寫事務，也就是begin了還未提交的事務。經過這個列表來判斷記錄的某個版本是否對當前事務可見。假設當前列表裏的事務id爲[80,100]。

• 若是你要訪問的記錄版本的事務id爲50，比當前列表最小的id80小，那說明這個事務在以前就提交了，因此對當前活動的事務來講是可訪問的。

• 若是你要訪問的記錄版本的事務id爲70,發現此事務在列表id最大值和最小值之間，那就再判斷一下是否在列表內，若是在那就說明此事務還未提交，因此版本不能被訪問。若是不在那說明事務已經提交，因此版本能夠被訪問。

• 若是你要訪問的記錄版本的事務id爲110，那比事務列表最大id100都大，那說明這個版本是在ReadView生成以後才發生的，因此不能被訪問。

這些記錄都是去版本鏈裏面找的，先找最近記錄，若是最近這一條記錄事務id不符合條件不可見的話，再去找上一個版本再比較當前事務的id和這個版本事務id看版本能不能訪問，以此類推直到返回可見的版本或者結束。

舉個例子 ，在已提交讀隔離級別下：

好比此時有一個事務id爲100的事務，修改了name,使得的name等於小明2，可是事務還沒提交。則此時的版本鏈是

那此時另外一個事務發起了select 語句要查詢id爲1的記錄，那此時生成的ReadView 列表只有[100]。那就去版本鏈去找了，首先確定找最近的一條，發現trx_id是100,也就是name爲小明2的那條記錄，發如今列表內，因此不能訪問。

這時候就經過指針繼續找下一條，name爲小明1的記錄，發現trx_id是60，小於列表中的最小id,因此能夠訪問，直接訪問結果爲小明1。

那這時候咱們把事務id爲100的事務提交了，而且新建了一個事務id爲110也修改id爲1的記錄，而且不提交事務

這是時候版本鏈就是

這時候以前那個select事務又執行了一次查詢,要查詢id爲1的記錄。

這個時候關鍵的地方來了

若是你是已提交讀隔離級別，這時候你會從新一個ReadView，那你的活動事務列表中的值就變了，變成了[110]。

按照上的說法，你去版本鏈經過trx_id對比查找到合適的結果就是小明2。

若是你是可重複讀隔離級別，這時候你的ReadView仍是第一次select時候生成的ReadView, 也就是列表的值仍是[100]。因此select的結果是小明1。因此第二次select結果和第一次同樣，因此叫可重複讀！

也就是說已提交讀隔離級別下的事務在每次查詢的開始都會生成一個獨立的ReadView,而可重複讀隔離級別則在第一次讀的時候生成一個ReadView，以後的讀都複用以前的ReadView。

這就是Mysql的MVCC,經過版本鏈，實現多版本，可併發讀-寫，寫-讀。經過ReadView生成策略的不一樣實現不一樣的隔離級別。

---

若有錯誤歡迎指正！

我的公衆號:yes的練級攻略

有相關面試進階(分佈式、性能調優、經典書籍pdf)資料等待領取