MySQL InnoDB之MVCC原理是什么

今天小編給大家分享一下MySQL InnoDB之MVCC原理是什么的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

MVCC全稱Multi-Version Concurrency Control，即多版本并發控制，主要是為了提高數據庫的并發性能。同一行數據平時發生讀寫請求時，會上鎖阻塞住。但MVCC用更好的方式去處理讀—寫請求，做到在發生讀—寫請求沖突時不用加鎖。這個讀是指的快照讀，而不是當前讀，當前讀是一種加鎖操作，是悲觀鎖。那它到底是怎么做到讀—寫不用加鎖的，快照讀和當前讀是指什么？我們后面都會學到。

MySQL在REPEATABLE READ隔離級別下，是可以很大程度避免幻讀問題的發生的，MySQL是怎么做到的？

版本鏈

我們知道，對于使用InnoDB存儲引擎的表來說，它的聚簇索引記錄中都包含兩個必要的隱藏列（row_id并不是必要的，我們創建的表中有主鍵或者非NULL的UNIQUE鍵時都不會包含row_id列）：

• trx_id：每次一個事務對某條聚簇索引記錄進行改動時，都會把該事務的事務id賦值給trx_id隱藏列。

• roll_pointer：每次對某條聚簇索引記錄進行改動時，都會把舊的版本寫入到undo日志中，然后這個隱藏列就相當于一個指針，可以通過它來找到該記錄修改前的信息。

為了說明這個問題，我們創建一個演示表：

CREATE TABLE `teacher` (
  `number` int(11) NOT NULL,
  `name` varchar(100) DEFAULT NULL,
  `domain` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`number`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

然后向這個表里插入一條數據：

mysql> insert into teacher values(1, 'J', 'Java');Query OK, 1 row affected (0.01 sec)

現在里的數據就是這樣的：

mysql> select * from teacher;
+--------+------+--------+
| number | name | domain |
+--------+------+--------+
|      1 | J    | Java   |
+--------+------+--------+
1 row in set (0.00 sec)

假設插入該記錄的事務id為60，那么此刻該條記錄的示意圖如下所示：

假設之后兩個事務id分別為80、120的事務對這條記錄進行UPDATE操作，操作流程如下：

每次對記錄進行改動，都會記錄一條undo日志，每條undo日志也都有一個roll_pointer屬性（INSERT操作對應的undo日志沒有該屬性，因為該記錄并沒有更早的版本），可以將這些undo日志都連起來，串成一個鏈表，所以現在的情況就像下圖一樣：

對該記錄每次更新后，都會將舊值放到一條undo日志中，就算是該記錄的一個舊版本，隨著更新次數的增多，所有的版本都會被roll_pointer屬性連接成一個鏈表，我們把這個鏈表稱之為版本鏈，版本鏈的頭節點就是當前記錄最新的值。另外，每個版本中還包含生成該版本時對應的事務id。于是可以利用這個記錄的版本鏈來控制并發事務訪問相同記錄的行為，那么這種機制就被稱之為多版本并發控制(Mulit-Version Concurrency Control MVCC)。

ReadView

對于使用READ UNCOMMITTED隔離級別的事務來說，由于可以讀到未提交事務修改過的記錄，所以直接讀取記錄的最新版本就好了。

對于使用SERIALIZABLE隔離級別的事務來說，InnoDB使用加鎖的方式來訪問記錄。

對于使用READ COMMITTED和REPEATABLE READ隔離級別的事務來說，都必須保證讀到已經提交了的事務修改過的記錄，也就是說假如另一個事務已經修改了記錄但是尚未提交，是不能直接讀取最新版本的記錄的，核心問題就是：READ COMMITTED和REPEATABLE READ隔離級別在不可重復讀和幻讀上的區別，這兩種隔離級別關鍵是需要判斷一下版本鏈中的哪個版本是當前事務可見的。

為此，InnoDB提出了一個ReadView的概念，這個ReadView中主要包含4個比較重要的內容：

• m_ids：表示在生成ReadView時當前系統中活躍的讀寫事務的事務id列表。

• min_trx_id：表示在生成ReadView時當前系統中活躍的讀寫事務中最小的事務id，也就是m_ids中的最小值。

• max_trx_id：表示生成ReadView時系統中應該分配給下一個事務的id值。注意max_trx_id并不是m_ids中的最大值，事務id是遞增分配的。比方說現在有id為1，2，3這三個事務，之后id為3的事務提交了。那么一個新的讀事務在生成ReadView時，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。

• creator_trx_id：表示生成該ReadView的事務的事務id。

有了這個ReadView，這樣在訪問某條記錄時，只需要按照下邊的步驟判斷記錄的某個版本是否可見：

1. 如果被訪問版本的trx_id屬性值與ReadView中的creator_trx_id值相同，意味著當前事務在訪問它自己修改過的記錄，所以該版本可以被當前事務訪問。

2. 如果被訪問版本的trx_id屬性值小于ReadView中的min_trx_id值，表明生成該版本的事務在當前事務生成ReadView前已經提交，所以該版本可以被當前事務訪問。

3. 如果被訪問版本的trx_id屬性值大于或等于ReadView中的max_trx_id值，表明生成該版本的事務在當前事務生成ReadView后才開啟，所以該版本不可以被當前事務訪問。

4. 如果被訪問版本的trx_id屬性值在ReadView的min_trx_id和max_trx_id之間(min_trx_id <= trx_id < max_trx_id)，那就需要判斷一下trx_id屬性值是不是在m_ids列表中，如果在，說明創建ReadView時生成該版本的事務還是活躍的，事務還沒提交，該版本不可以被訪問；如果不在，說明創建ReadView時生成該版本的事務已經被提交，該版本可以被訪問。

5. 如果某個版本的數據對當前事務不可見的話，那就順著版本鏈找到下一個版本的數據，繼續按照上邊的步驟判斷可見性，依此類推，直到版本鏈中的最后一個版本。如果最后一個版本也不可見的話，那么就意味著該條記錄對該事務完全不可見，查詢結果就不包含該記錄。

在MySQL中，READ COMMITTED和REPEATABLE READ隔離級別的的一個非常大的區別就是它們生成ReadView的時機不同。

我們還是以表teacher為例，假設現在表teacher中只有一條由事務id為60的事務插入的一條記錄，接下來看一下READ COMMITTED和REPEATABLE READ所謂的生成ReadView的時機不同到底不同在哪里。

READ COMMITTED每次讀取數據前都生成一個ReadView

假設現在系統里有兩個事務id分別為80、120的事務在執行：

# Transaction 80
set session transaction isolation level read committed;
begin
update teacher set name='S' where number=1;
update teacher set name='T' where number=1;

此刻，表teacher中number為1的記錄得到的版本鏈表如下所示：

假設現在有一個使用READ COMMITTED隔離級別的事務開始執行：

set session transaction isolation level read committed;
# 使用READ COMMITTED隔離級別的事務
begin;
# SELECE1：Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'J'

這個SELECE1的執行過程如下：

• 在執行SELECT語句時會先生成一個ReadView，ReadView的m_ids列表的內容就是[80, 120]，min_trx_id為80，max_trx_id為121，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，最新版本的列name的內容是’T’，該版本的trx_id值為80，在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’S’，該版本的trx_id值也為80，也在m_ids列表內，根據步驟4也不符合要求，繼續跳到下一個版本。

• 下一個版本的列name的內容是’J’，該版本的trx_id值為60，小于ReadView 中的min_trx_id值，根據步驟2判斷這個版本是符合要求的。

之后，我們把事務id為80的事務提交一下，然后再到事務id為120的事務中更新一下表teacher 中number為1的記錄：

set session transaction isolation level read committed;
# Transaction 120
begin
update teacher set name='K' where number=1;
update teacher set name='F' where number=1;

此刻，表teacher 中number為1的記錄的版本鏈就長這樣：

然后再到剛才使用READ COMMITTED隔離級別的事務中繼續查找這個number 為1的記錄，如下：

# 使用READ COMMITTED隔離級別的事務
begin;
# SELECE1：Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'J'
# SELECE2：Transaction 80提交、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'T'

這個SELECE2 的執行過程如下：

• 在執行SELECT語句時會又會單獨生成一個ReadView，該ReadView的m_ids列表的內容就是[120]（事務id為80的那個事務已經提交了，所以再次生成快照時就沒有它了），min_trx_id為120，max_trx_id為121，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內容是’F’，該版本的trx_id值為120，在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name 的內容是’K’，該版本的trx_id值為120，也在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’T’，該版本的trx_id值為80，小于ReadView中的min_trx_id值120，表明生成該版本的事務在當前事務生成ReadView前已經提交，所以這個版本是符合要求的，最后返回給用戶的版本就是這條列name為’‘T’'的記錄。

以此類推，如果之后事務id為120的記錄也提交了，再次在使用READCOMMITTED隔離級別的事務中查詢表teacher中number值為1的記錄時，得到的結果就是’F’了，具體流程我們就不分析了。

總結一下就是：使用READCOMMITTED隔離級別的事務在每次查詢開始時都會生成一個獨立的ReadView。

REPEATABLE READ —— 在第一次讀取數據時生成一個ReadView

對于使用REPEATABLE READ隔離級別的事務來說，只會在第一次執行查詢語句時生成一個ReadView，之后的查詢就不會重復生成了。我們還是用例子看一下是什么效果。

假設現在系統里有兩個事務id分別為80、120的事務在執行：

# Transaction 80
begin
update teacher set name='S' where number=1;
update teacher set name='T' where number=1;

此刻，表teacher中number為1的記錄得到的版本鏈表如下所示：

假設現在有一個使用REPEATABLE READ隔離級別的事務開始執行：

# 使用REPEATABLE READ隔離級別的事務
begin;
# SELECE1：Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'J'

這個SELECE1的執行過程如下（與READ COMMITTED的過程一致）：

• 在執行SELECT語句時會先生成一個ReadView，ReadView的m_ids列表的內容就是[80, 120]，min_trx_id為80，max_trx_id為121，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，最新版本的列name的內容是’T’，該版本的trx_id值為80，在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’S’，該版本的trx_id值也為80，也在m_ids列表內，根據步驟4也不符合要求，繼續跳到下一個版本。

• 下一個版本的列name的內容是’J’，該版本的trx_id值為60，小于ReadView 中的min_trx_id值，根據步驟2判斷這個版本是符合要求的。

之后，我們把事務id為80的事務提交一下，然后再到事務id為120的事務中更新一下表teacher 中number為1的記錄：

# Transaction 80
begin
update teacher set name='K' where number=1;
update teacher set name='F' where number=1;

此刻，表teacher 中number為1的記錄的版本鏈就長這樣：

然后再到剛才使用REPEATABLE READ隔離級別的事務中繼續查找這個number為1的記錄，如下：

# 使用REPEATABLE READ隔離級別的事務
begin;
# SELECE1：Transaction 80、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'J'
# SELECE2：Transaction 80提交、120未提交
SELECT * FROM teacher WHERE number = 1; # 得到的列name的值為'J'

這個SELECE2的執行過程如下：

• 因為當前事務的隔離級別為REPEATABLE READ，而之前在執行SELECE1時已經生成過ReadView了，所以此時直接復用之前的ReadView，之前的ReadView的m_ids列表的內容就是[80, 120]，min_trx_id為80，max_trx_id為121，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內容是’F’，該版本的trx_id值為120，在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’K’，該版本的trx_id值為120，也在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’T’，該版本的trx_id值為80，也在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’S’，該版本的trx_id值為80，也在m_ids列表內，根據步驟4不符合可見性要求，根據roll_pointer跳到下一個版本。

• 下一個版本的列name的內容是’J’，該版本的trx_id值為60，小于ReadView中的min_trx_id值80，表明生成該版本的事務在當前事務生成ReadView前已經提交，所以這個版本是符合要求的，最后返回給用戶的版本就是這條列name為’‘J’'的記錄。

也就是說兩次SELECT查詢得到的結果是重復的，記錄的列值都是’’‘J’’’，這就是可重復讀的含義。

如果我們之后再把事務id為120的記錄提交了，然后再到剛才使用REPEATABLE READ隔離級別的事務中繼續查找這個number為1的記錄，得到的結果還是’J’，具體執行過程大家可以自己分析一下。

MVCC下的幻讀現象和幻讀解決

前面我們已經知道了，REPEATABLE READ隔離級別下MVCC可以解決不可重復讀問題，那么幻讀呢？MVCC是怎么解決的？幻讀是一個事務按照某個相同條件多次讀取記錄時，后讀取時讀到了之前沒有讀到的記錄，而這個記錄來自另一個事務添加的新記錄。

我們可以想想，在REPEATABLE READ隔離級別下的事務T1先根據某個搜索條件讀取到多條記錄，然后事務T2插入一條符合相應搜索條件的記錄并提交，然后事務T1再根據相同搜索條件執行查詢。結果會是什么？按照ReadView中的比較規則：

不管事務T2比事務T1是否先開啟，事務T1都是看不到T2的提交的。請自行按照上面介紹的版本鏈、ReadView以及判斷可見性的規則來分析一下。

但是，在REPEATABLE READ隔離級別下InnoDB中的MVCC可以很大程度地避免幻讀現象，而不是完全禁止幻讀。怎么回事呢？我們來看下面的情況：

嗯，怎么回事？事務T1很明顯出現了幻讀現象。在REPEATABLE READ隔離級別下，T1第一次執行普通的SELECT語句時生成了一個ReadView，之后T2向teacher表中新插入一條記錄并提交。ReadView并不能阻止T1執行UPDATE或者DELETE語句來改動這個新插入的記錄（由于T2已經提交，因此改動該記錄并不會造成阻塞)，但是這樣一來，這條新記錄的trx_id隱藏列的值就變成了T1的事務id。之后T1再使用普通的SELECT語句去查詢這條記錄時就可以看到這條記錄了，也就可以把這條記錄返回給客戶端。因為這個特殊現象的存在，我們也可以認為MVCC并不能完全禁止幻讀。

MVCC小結

從上邊的描述中我們可以看出來，所謂的MVCC（Multi-Version ConcurrencyControl ，多版本并發控制）指的就是在使用READ COMMITTD、REPEATABLE READ這兩種隔離級別的事務在執行普通的SELECT操作時訪問記錄的版本鏈的過程，這樣子可以使不同事務的讀-寫、寫-讀操作并發執行，從而提升系統性能。

READ COMMITTD、REPEATABLE READ這兩個隔離級別的一個很大不同就是：生成ReadView的時機不同，READ COMMITTD在每一次進行普通SELECT操作前都會生成一個ReadView，而REPEATABLE READ只在第一次進行普通SELECT操作前生成一個ReadView，之后的查詢操作都重復使用這個ReadView就好了，從而基本上可以避免幻讀現象。

我們之前說執行DELETE語句或者更新主鍵的UPDATE語句并不會立即把對應的記錄完全從頁面中刪除，而是執行一個所謂的delete mark操作，相當于只是對記錄打上了一個刪除標志位，這主要就是為MVCC服務的。另外，所謂的MVCC只是在我們進行普通的SEELCT查詢時才生效，截止到目前我們所見的所有SELECT語句都算是普通的查詢，至于什么是個不普通的查詢，后面就會講到。

以上就是“MySQL InnoDB之MVCC原理是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。