狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

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

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

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執行會非常快，無法驗證同時執行的兩個事務之間是否存在阻塞情況，所以需要顯示開啟事務和提交事務。

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

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

事務2 的執行記錄：

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

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

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

我的認知一直是錯誤的。

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

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

本以為驗證結束，打卡下班，結果發現 MySQL插入似乎存在幻讀問題！

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

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

所謂幻讀，是指在一個事務讀取記錄時，另一個事務在此時插入或刪除了一條記錄，導致第一個事務再次讀取時發現記錄的數量發生了變化。

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

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

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

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

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

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

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

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

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

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

操作順序如下：

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

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

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

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

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

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

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

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

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

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

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

那 ReadView 又是何時生成的呢？

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

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

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