最近筆者和同事爭辯起來，MySQL插入是并發(fā)還是串行，我記得明明是串行插入，同事非要和我杠，說MySQL可以并發(fā)插入。

我要親自試驗一下，打他的臉！

MySQL實驗版本：8.0。

首先定義 用戶信息表userInfo，其中id為自增，name具有唯一索引。

CREATE TABLE `userInfo` (  `id` int NOT NULL AUTO_INCREMENT,  `name` varchar(50) NOT NULL,  `password` varchar(50) NOT NULL,  PRIMARY KEY (`id`),  UNIQUE KEY `name` (`name`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4

默認情況下，在命令行中 MySQL會自動提交，每個SQL執(zhí)行會非?？?，無法驗證同時執(zhí)行的兩個事務(wù)之間是否存在阻塞情況，所以需要顯示開啟事務(wù)和提交事務(wù)。

首先，我們開啟兩個事務(wù)。在事務(wù)1中，首先插入一條記錄，暫時不提交。然后，在事務(wù)2中開啟一個新的事務(wù)，并插入一條自增記錄。

如果MySQL的innodb插入是串行的，那么此時事務(wù)2的插入記錄將會被阻塞。如果沒有被阻塞，那就說明MySQL的innodb插入是并發(fā)執(zhí)行的。

事務(wù)2 的執(zhí)行記錄：

如上圖所示，在事務(wù)1還未提交，事務(wù)2在事務(wù)1的間隙中插入一條記錄，插入操作立即成功，并且事務(wù)2的自增主鍵ID為2。這說明在MySQL中，當一個事務(wù)正在插入記錄時，并不會阻塞其他事務(wù)的插入。

在MySQL中，多個事務(wù)之間的插入操作是并發(fā)進行的，而不是串行進行的。

我感覺自己的臉熱熱的，小丑竟是我自己，趕緊給同事認了錯……

我的認知一直是錯誤的。

但是在底層存儲層面，MySQL會對數(shù)據(jù)頁加鎖。如果兩條記錄在同一個數(shù)據(jù)頁，實際寫入是串行的，但是事務(wù)層面是并發(fā)的。

想象一下，庫存扣減和新增庫存流水在同一個事務(wù)中，如果新增庫存流水是串行的，那將極大的降低庫存事務(wù)的并發(fā)度啊。

本以為驗證結(jié)束，打卡下班，結(jié)果發(fā)現(xiàn) MySQL插入似乎存在幻讀問題！

從下圖中可以觀察到，事務(wù)1在插入時似乎確實出現(xiàn)了幻讀問題！

事務(wù) 1 的執(zhí)行記錄顯示，事務(wù)1先于事務(wù)2開啟，但是事務(wù)1期間可以查詢到事務(wù)2提交的記錄。這說明有幻讀問題！

所謂幻讀，是指在一個事務(wù)讀取記錄時，另一個事務(wù)在此時插入或刪除了一條記錄，導(dǎo)致第一個事務(wù)再次讀取時發(fā)現(xiàn)記錄的數(shù)量發(fā)生了變化。

要想理解出現(xiàn)幻讀的原因，需要先了解MySQL是如何解決幻讀問題的。

為了解決幻讀問題，MySQL采用了間隙鎖和多版本并發(fā)控制（MVCC）的方法。間隙鎖會鎖定一段記錄的范圍，其他事務(wù)無法對這些記錄進行更新或刪除操作。這樣，當當前事務(wù)再次進行查詢時，就不會出現(xiàn)記錄數(shù)量的新增或減少的情況了。

MySQL 插入時存在幻讀問題，說明MySQL 并沒有加間隙鎖，主要考慮也是為了提高插入時并發(fā)度，如果添加間隙鎖，勢必導(dǎo)致插入并發(fā)度降低！MySQL 在插入之前會申請 插入意向鎖，而記錄本身不沖突（無唯一鍵沖突）插入意向鎖就不會沖突。

MySQL 文檔中記錄了 插入意向鎖：

插入意向鎖（insert intention lock）是一種由插入操作在插入行之前設(shè)置的鎖定類型。這種鎖定方式表示插入的意圖，使得在相同索引間隙上進行插入的多個事務(wù)在插入位置不沖突的情況下不需要互相等待。假設(shè)索引記錄中存在值為4和7的記錄。分別嘗試插入值為5和6的兩個不同事務(wù)，在獲得插入行的排他鎖之前，它們會先使用插入意向鎖鎖定位于4和7之間的間隙，并且由于插入行不沖突，它們不會互相阻塞。

除更新場景外，查詢場景也有幻讀的困惱。如果第一次查詢時只有3條記錄，再次查詢則變?yōu)?條，實在過于奇幻。

如果給普通的查詢語句添加間隙鎖，勢必極大的降低MySQL 的并發(fā)度，如果不能使用間隙鎖，還有哪些辦法解決幻讀呢？

MySQL 通過引入MVCC解決查詢場景的幻讀問題。MVCC是多版本并發(fā)控制（Multiversion Concurrency Control）的縮寫，在MVCC中，每個事務(wù)可以看到數(shù)據(jù)庫的一個穩(wěn)定的快照，而不會被其他并發(fā)事務(wù)的修改所干擾。當一個事務(wù)修改數(shù)據(jù)庫時，它會創(chuàng)建一個新的數(shù)據(jù)版本，而不是直接在原始數(shù)據(jù)上進行修改。而其他事務(wù)仍然可以讀取原始數(shù)據(jù)的舊版本或者已經(jīng)提交的新版本，這樣就避免了讀取到未提交的數(shù)據(jù)或者被其他事務(wù)的寫操作所阻塞。

MVCC的實現(xiàn)通常涉及對每個數(shù)據(jù)行或數(shù)據(jù)塊分配一個唯一的標識符，稱為"事務(wù)ID"。每個事務(wù)也有自己的唯一ID。當一個事務(wù)讀取數(shù)據(jù)時，系統(tǒng)會檢查該數(shù)據(jù)的事務(wù)ID與事務(wù)的ID是否兼容，以確定是否允許讀取。如果事務(wù)的ID大于數(shù)據(jù)的事務(wù)ID，那么說明數(shù)據(jù)是過期的，事務(wù)將無法讀取。這種機制保證了事務(wù)在讀取數(shù)據(jù)時的隔離性和一致性。

當我在苦苦思考，為什么MVCC 沒有生效時，我隨手重新測試發(fā)現(xiàn)，如果在 insert 語句之前，使用 select 查詢一下，就不會出現(xiàn)幻讀問題。

操作順序如下：

我在事務(wù)1，開啟事務(wù)以后，新增了 select 語句查詢，而后第六步，就不會再有幻讀問題……

這實在太奇幻了，一波三折……

由此可見 MySQL 插入并沒有幻讀問題，只是我的打開方式不對。我應(yīng)該先 select一下 ……，終究還是我錯了，但是我想問為什么？我為什么錯了？

除MVCC 外，MySQL InnoDB 引擎設(shè)計了 ReadView（可讀視圖） 的概念。

ReadView 判斷記錄的可見性，ReadView 實際上是當前系統(tǒng)中所有活躍事務(wù)的列表，主要包含以下組成部分：

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

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

2）如果被訪問版本的 trx_id 屬性值小于 ReadView 中的 min_trx_id 值，表明生成該版本的事務(wù)在當前事務(wù)生成 ReadView 前已經(jīng)提交，所以該版本記錄可以被當前事務(wù)訪問。

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

4）如果被訪問版本的 trx_id 屬性值在 ReadView 的 min_trx_id 和 max_trx_id 之間，那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中，如果在，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)還是活躍的，該版本不可以被訪問；如果不在，說明創(chuàng)建 ReadView 時生成該版本的事務(wù)已經(jīng)被提交，該版本記錄可以被訪問。如果某個版本的記錄對當前事務(wù)不可見的話，那就順著版本鏈找到下一個版本的數(shù)據(jù)，繼續(xù)按照上邊的步驟判斷可見性，依此類推，直到版本鏈中的最后一個版本。如果最后一個版本也不可見的話，那么就意味著該條記錄對該事務(wù)完全不可見，查詢結(jié)果就不包含該記錄。

總結(jié)一下就是：如果當前事務(wù)id的生成時間發(fā)生在 記錄的更新之后，那么當前事務(wù)就可以看見這個記錄，否則看不見！避免幻讀問題。

那 ReadView 又是何時生成的呢？

在 Read committed RC 隔離級別下，每個事務(wù)執(zhí)行第一個 SELECT 語句時，會將當前系統(tǒng)中的所有的活躍事務(wù)拷貝到一個列表生成 ReadView，后續(xù)所有的 SELECT 都是復(fù)用這個 ReadView。

REPEATABLE READ RR 隔離級別下，只有第一次 SELECT 才會生成 ReadView，后續(xù) SELECT 都會復(fù)用這個 ReadView，也就不存在新提交事務(wù)對這個 ReadView 的影響了。

所以 當我在 事務(wù) 1 新增select語句，會生成一個ReadView，這個ReadView 生成時間要早于 事務(wù)2的時間，所以事務(wù)1 的后續(xù)所有查詢都不會看到事務(wù)2的記錄，從而避免幻讀問題發(fā)生。