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

我要親自試驗(yàn)一下，打他的臉！

MySQL實(shí)驗(yàn)版本：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

默認(rèn)情況下，在命令行中 MySQL會(huì)自動(dòng)提交，每個(gè)SQL執(zhí)行會(huì)非常快，無法驗(yàn)證同時(shí)執(zhí)行的兩個(gè)事務(wù)之間是否存在阻塞情況，所以需要顯示開啟事務(wù)和提交事務(wù)。

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

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

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

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

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

我感覺自己的臉熱熱的，小丑竟是我自己，趕緊給同事認(rèn)了錯(cuò)……

我的認(rèn)知一直是錯(cuò)誤的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

操作順序如下：

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

這實(shí)在太奇幻了，一波三折……

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

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

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

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

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

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

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

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

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

那 ReadView 又是何時(shí)生成的呢？

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

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

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