前言

RR解決臟讀、不可重復讀、幻讀等問題，使用的是MVCC（Multi-Version Concurrency Control），即多版本的并發控制協議，在了解 MVCC 之前，我們先來聊聊隱藏列、Undo log 和 Read View，

隱藏列

InnoDB中每行資料除了我們創建的欄位外還有有隱藏列，其中隱藏列包含了本行資料的事務id、指向undo log的指標等，

Undo log

MVCC 的實作是通過 Undo log 來完成的，當用戶讀取一行記錄時，若該記錄已經被其它事務占用，當前事務可以通過 Undo log 讀取之前的行版本資訊，因為沒有事務需要對歷史的資料進行修改操作，所以也不需要加鎖，以此來實作非鎖定讀取，

Undo log（回滾日志）可以查看我之前整理的文章-----mysql日志檔案總結

Read View

什么是readview

事務(暫記事務1)在某一時刻給事務系統trx_sys打快照，把當時trx_sys狀態（包括活躍讀寫事務陣列）記下來，之后的所有讀操作根據其事務id（即trx_id）與快照中的trx_sys的狀態作比較，以此判斷readview對于事務1的可見性，

Read View 中大致包含以下內容：

trx_ids：資料庫系統當前活躍事務 ID 集合；
low_limit_id：活躍事務中最大的事務 ID +1；
up_limt_id：活躍事務總最小的事務 ID；
creator_trx_id：創建這個 Read View 的事務 ID，

比如某個事務，創建了 Read View，那么它的 creator_trx_id 就為這個事務的 ID，假如需要訪問某一行，假設這一行記錄的隱藏事務 ID 為 t_id，那么可能出現的情況如下：

如果 t_id < up_limt_id，說明這行記錄在這些活躍的事務創建之前就已經提交了，那么這一行記錄對該事務是可見的，
如果 t_id >= low_limt_id，說明這行記錄在這些活躍的事務開始之后創建的，那么這一行記錄對該事物是不可見的，
如果 up_limit_id <= t_id < low_limit_id，說明這行記錄可能是在這些活躍的事務中創建的，如果 t_id 也同時在 trx_ids 中，則說明 t_id 還未提交，那么這一行記錄對該事物是不可見的；如果 t_id 不在 trx_ids 中，則說明事務 t_id 已經提交了，那么這一行記錄對該事物是可見的，

什么是MVCC

MVCC，即多版本并發控制，MVCC 的實作，是通過保存資料在某個時間點的快照來實作的，也就是說，不管需要執行多長時間，每個事務看到的資料都是一致的，根據事務開始的時間不同，每個事務對同一張表，同一時刻看到的資料可能是不一樣的，

MVCC舉例說明

# 首先開啟兩個臨時客戶端，將默認隔離級別改成RC
mysql> set session transaction isolation level READ COMMITTED;
Connection id:    7713
Current database: muke
Query OK, 0 rows affected (0.06 sec)
mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set, 1 warning (0.00 sec)

# 客戶端1
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
# 首先查看t21 b為4的資料
mysql> select * from t21 where b = 4;
+----+---+---+
| id | a | b |
+----+---+---+
|  4 | 4 | 4 |
+----+---+---+
1 rows in set (0.00 sec)

mysql> update t21 set b = 44 where b = 4;
Query OK, 1 rows affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select sleep(10);
+-----------+
| sleep(10) |
+-----------+
|         0 |
+-----------+
1 row in set (10.01 sec)
mysql> rollback;
Query OK, 0 rows affected (0.01 sec)


# 客戶端2 
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t21 where b = 4;
+----+---+---+
| id | a | b |
+----+---+---+
|  4 | 4 | 4 |
+----+---+---+
1 rows in set (0.00 sec)
# 在客戶端執行select sleep(10);在執行查詢陳述句
mysql> select * from t21 where b = 4;
+----+---+---+
| id | a | b |
+----+---+---+
|  4 | 4 | 4 |
+----+---+---+
1 rows in set (0.00 sec)

mysql> rollback;
Query OK, 0 rows affected (0.00 sec)

從上面執行現象可以看出：客戶端1的事務先于客戶端2的事務執行，但是發現在客戶端1休眠的時候，事務2很快就執行完畢并回傳了結果，如果RC模式下讀操作需要獲取S鎖，但是因為當前已經有了X鎖，兩個鎖是互斥的，理論上S鎖需要等待X鎖釋放才會獲取，但是并沒有發生這種情況，可以看出讀操作并沒有使用S鎖，而是使用MVCC實作的，

在實驗中，客戶端2 查詢的結果是客戶端1 修改之前的記錄，也就是那個點的 Read View，根據上面將的 Read View 原理，被查詢行的隱藏事務 ID 就在當前活躍事務 ID 集合中，因此，這一行記錄對該事物（客戶端2中的事務）是不可見的，可以知道客戶端2 查詢的 b=4 記錄實際就是來自 Undo log 中，我們看到的現象就是同一條記錄在系統中存在了多個版本，這就是多版本并發控制（MVCC），

圖例

擴展知識

RR隔離級別（除了Gap鎖(間隙鎖)之外）和RC隔離級別的差別是創建snapshot時機不同， RR隔離級別是在事務開始時刻，確切地說是第一個讀操作創建read view的；RC隔離級別是在陳述句開始時刻創建read view的，
創建/關閉read view需要持有mutex，會降低系統性能，5.7版本對此進行優化，在事務提交時session會cache只讀事務的read view，
下次創建read view，判斷如果是只讀事務并且系統的讀寫事務狀態沒有發生變化，即trx_sys的max_trx_id沒有向前推進，而且沒有新的讀寫事務產生，就可以重用上次的read view，
MVCC 最大的好處是讀不加鎖，讀寫不沖突，極大地增加了 MySQL 的并發性，通過 MVCC，保證了事務隔離性，
MVCC 為什么只在 RC 和 RR 兩個隔離級別下作業？

RU: 每次只取最新的值，不存在多個值的情況，串行：每次查詢會加讀鎖，當有更新時會阻塞住，只有等到查詢完鎖釋放后，才會做更新操作，由此可知RU和串行的隔離級別下，只會存在一個值，不存在多個值的情況，MVCC是解決并發情況下，同時可能產生多個值，從多個值中查詢出一個準確值的技術，所以RU,串行是用不到MVCC技術

學習鏈接

MySQL的MVCC在各種隔離級別中發揮的作用

MySQL · 原始碼分析 · InnoDB的read view，回滾段和purge程序簡介

深入學習MySQL事務：ACID特性的實作原理

mysql事務-----四種隔離級別

mysql日志檔案總結

人們以為他們的理性支配言語，偏偏有時反而支配理性， ---培根

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/164338.html

標籤：其他

下一篇：DBUtils工具類的使用方法詳解

淺析mvcc原理

前言

隱藏列