前言

RR解決髒讀、不可重複讀、幻讀等問題，使用的是MVCC（Multi-Version Concurrency Control），即多版本的併發控制協議。在瞭解 MVCC 以前，咱們先來聊聊隱藏列、Undo log 和 Read View。html

隱藏列

InnoDB中每行數據除了咱們建立的字段外還有有隱藏列，其中隱藏列包含了本行數據的事務id、指向undo log的指針等。mysql

Undo log

MVCC 的實現是經過 Undo log 來完成的。當用戶讀取一行記錄時，若該記錄已經被其它事務佔用，當前事務能夠經過 Undo log 讀取以前的行版本信息，由於沒有事務須要對歷史的數據進行修改操做，因此也不須要加鎖，以此來實現非鎖定讀取。sql

Undo log（回滾日誌）能夠查看我以前整理的文章-----mysql日誌文件總結數據庫

Read View數組

什麼是readview

事務(暫記事務1)在某一時刻給事務系統trx_sys打快照，把當時trx_sys狀態（包括活躍讀寫事務數組）記下來，以後的全部讀操做根據其事務id（即trx_id）與快照中的trx_sys的狀態做比較，以此判斷readview對於事務1的可見性。bash

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，那麼可能出現的狀況以下：session

若是 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日誌文件總結

人們覺得他們的理性支配言語，恰恰有時反而支配理性。 ---培根

淺析mvcc原理

前言

隱藏列