對Mysql的MVCC的理解是什么

今天就跟大家聊聊有關對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的理解是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。