你是否對 MySQL 數據庫中的事務已經有所了解？看下面這張圖，按照 1～6 的順序依次執行，在RR隔離級別下，事務 A 和事務 B 各自輸出的 num 值是多少嗎？

我們預先創建好這樣一張表并初始化一條數據：

CREATETABLE`test1`(
`id`int(11)NOTNULLAUTO_INCREMENTCOMMENT'主鍵Id',
`num`int(11)NULLCOMMENT'數量',
PRIMARYKEY(`id`)
)ENGINE=InnoDB;

insertintotest1(id,num)values(1,1);

然后開始按上圖的順序執行各個事務，這需要我們打開3個操作窗口來分別執行 A、B、C 三個事務：

事務 A：

事務 B：

事務 C：

按照上圖的執行順序執行 commit，其中事務 C 是自動提交事務的，不需要我們顯示的 commit，事務 A、B 的輸出結果如下：

事務A：num=1

事務B：num=3

為什么是這樣輸出？

它的背后其實是：MVCC（多版本并發控制）、consistent read（一致性讀）、locking reads（鎖定讀）等 MySQL 數據庫底層知識。

1、MVCC

MySQL 數據庫官網文檔是這樣來描述 MVCC 的：

多版本控制: 指的是一種提高并發的技術。最早的數據庫系統，只有讀讀之間可以并發，讀寫，寫讀，寫寫都要阻塞。引入多版本之后，只有寫寫之間相互阻塞，其他三種操作都可以并行，這樣大幅度提高了 InnoDB 的并發度。在內部實現中，與 Postgres 在數據行上實現多版本不同，InnoDB 是在 undolog 中實現的，通過 undolog 可以找回數據的歷史版本。

找回的數據歷史版本可以提供給用戶讀(按照隔離級別的定義，有些讀請求只能看到比較老的數據版本)，也可以在回滾的時候覆蓋數據頁上的數據。在 InnoDB 內部中，會記錄一個全局的活躍讀寫事務數組，其主要用來判斷事務的可見性。

目前來看 MVCC 的實現依賴于：

隱藏字段（DB_TRX_ID、DB_ROLL_PTR）

回滾日志（undo log）

一致性讀（consistent read）

你也可以這樣去理解 MVCC：一個事務對數據進行更新操作時候，先把舊的數據放到一個單獨的地方（回滾段），其他事務讀取數據時候，根據 DB_TRX_ID、DB_ROLL_PTR 計算出 undo log 鏈中當前版本的數據。

2、一致性讀（consistent read）

繼續看官方文檔對 consistent read 的描述：

直譯：

一個讀操作使用基于某個時刻的快照信息來顯示查詢結果，而不考慮同時運行的其他事務所執行的更改。如果查詢到的數據被其他事務所更改，則根據 undo log 中的內容來重建原始數據。這種技術避免了一些通過強制事務等待其他事務完成而降低并發性的鎖定問題。

在 RR 級別下，首次讀操作被執行時候創建一致性讀視圖 ReadView，事務的后續讀都基于該視圖的數據；

在 RC 級別下，每一次讀操作都會創建一個最新的 ReadView，因此每次 select 讀都可以獲取到當前已提交事務的最新數據。

“一致性讀”是 InnoDB 引擎在 RC 和 RR 隔離級別下處理 select 語句的默認模式。因為一個“一致性讀”是不需要對它訪問的表設置任何的鎖，當對表執行“一致性讀”時候，其他會話可以自由的修改這些表。

另外：

讀未提交（read uncommitted）、串行化（serializable）是不需要依賴 MVCC 的，讀未提交直接每次都讀取當前數據的最新值即可。而 serializable 是直接采用加鎖的操作讓所有的事務都串行化執行，犧牲了并發能力。

一致性讀的實現方式：

每個事務啟動的瞬間，都會構建一個數組（m_ids），用來記錄目前所有“活躍事務”（事務啟動了，但是還沒提交）的 ID；

數組中的最小事務 ID 為低水位;

數組中的最大事務 ID + 1 為高水位；

數據版本可見性規則：當前數據某個版本是否可見，取決于當前數據的 DB_TRX_ID 以及這個一致性視圖數組中記錄的事務 ID 做對比來判斷：低水位以前的數據版本可見，高水位以后的數據版本不可見，低水位和高水位之間得查看當前數據版本的 DB_TRX_ID 是否存在數組中，若存在意味著事務未提交，不可見，若不存在意味著事務已提交，可見。

那按照一致性讀的理解，事務B已經創建了自己的快照數據了，它的輸出應該是 num = 2 呀，為什么會是 num=3？

可是如果不是 num=3，那么已經提交的事務 C 的操作不就丟失了嗎？（產生丟失更新問題）

這里又涉及到一個知識點：

更新數據都是先讀后寫的，而這個讀，只能讀當前的值，稱為“當前讀”（current read）。

3、當前讀（current reads）

也叫做鎖定讀（locking reads）

InnoDB 引擎支持兩種方式的鎖定讀以提供額外的安全性（MySQL 5.7 版本）：

#讀鎖（S鎖，共享鎖）
SELECT...LOCKINSHAREMODE;
#寫鎖（X鎖，排他鎖）
SELECT...FORUPDATE;

鎖定讀會在被讀取的數據上加一把共享鎖，其他事務可以讀取記錄，但是不可以修改記錄，直到當前事務提交。

鎖定讀驗證：

為什么要有鎖定讀？

如果你在一個事務中先查詢了一個數據，然后插入或者更新相關的數據，這個時候來了一個事務B同時更新或者刪除你要查詢的記錄，就會出現幻讀問題了。

這也是為什么 MVCC 不能完全解決幻讀的問題，而是需要 MVCC + 行鎖 + 間隙鎖（next-key lock）的方式。

4、事務 A、B、C 的執行流程

繼續看開頭的第一張圖：

starttransactionwithconsistentsnapshot;

這條 SQL 語句可以立即啟動事務，創建當前事務的一致性讀快照。效果等同于 start transaction 然后馬上執行 select 語句。

我們接下來看看文章開頭的三個事務對數據行的修改流程，按照步驟 1～6 的操作如下：

如果大家細致的查看上圖的三個事務的穿插執行流程，可以發現，A、B、C 三個事務無論是 commit 還是 rollback，都是可以最終得到正確的數據。

這就是 InnoDB 引擎下的多版本并發控制（MVCC）的實現原理。

總結以下幾個關鍵點：

每一個事務都會創建一個數據快照，快照創建的時機根據隔離級別的不同有所區別；

每一個事務都會生成一個全局唯一的 DB_TRX_ID，用于標記當前版本；

DB_ROLL_PTR 是回滾指針的意思，結合 DB_TRX_ID 來最終確定我要拿到的數據；

DB_TRX_ID、DB_ROLL_PTR、undo log 這三個值來控制數據的版本；

update、delete 操作都是先讀后寫，這個讀屬于鎖定讀（當前讀）。

審核編輯：劉清