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，比當前列表最小的事務id爲80的小，那說明這個事務在之前就提交了，所以對當前活動的事務來說是可訪問的。
如果你要訪問的記錄版本的事務id爲90,發現此事務在列表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生成策略的不同實現不同的隔離級別。