第二種情況：

也就是基於上一種情況 事務A在事務B插入資料之前沒有進行select 沒有建立一個當前時間點的快照，

所以事務A ，在事務B 插入資料並提交後 再進行查詢操作就會出現幻讀

InnoDB通過Nextkey lock解決了當前讀時的幻讀問題

Innodb行鎖分為:

型別 —————- 說明
Record Lock: 在索引上對單行記錄加鎖.
Gap Lock: 鎖定一個範圍的記錄,但不包括記錄本身.鎖加在未使用的空閒空間上,可能是兩個索引記錄之間，也可能是第一個索引記錄之前或最後一個索引之後的空間.
Next-Key Lock: 行鎖與間隙鎖組合起來用就叫做Next-Key Lock。鎖定一個範圍，並且鎖定記錄本身。對於行的查詢，都是採用該方法，主要目的是解決幻讀的問題。

建立表：（切記：是key(id)，不是primary key(id)）

([email protected]) [fandb]> create table t5(id int,key(id));
Query OK, 0 rows affected (0.02 sec)

SESSION_A>insert into t5 values(1),(4),(7),(10);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0


開始實驗：
SESSION_A>begin;
Query OK, 0 rows affected (0.00 sec)

 
SESSION_A>select * from t5;
+------+
| id   |
+------+
|    1 |
|    4 |
|    7 |
|   10 |
+------+
4 rows in set (0.00 sec)

SESSION_A>select * from t5 where id=7 for update;
+------+
| id   |
+------+
|    7 |
+------+
1 row in set (0.00 sec)


SESSION_B>begin;
Query OK, 0 rows affected (0.00 sec)

 
SESSION_B>insert into t5 values(2);
Query OK, 1 row affected (0.00 sec)

SESSION_B>insert into t5 values(12);
Query OK, 1 row affected (0.00 sec)

SESSION_B>insert into t5 values(5); --被阻塞
^CCtrl-C -- sending "KILL QUERY 93" to server ...
Ctrl-C -- query aborted.
^[[AERROR 1317 (70100): Query execution was interrupted

SESSION_B>insert into t5 values(7); --被阻塞
^CCtrl-C -- sending "KILL QUERY 93" to server ...
Ctrl-C -- query aborted.
ERROR 1317 (70100): Query execution was interrupted

SESSION_B>insert into t5 values(9); --被阻塞
^CCtrl-C -- sending "KILL QUERY 93" to server ...
Ctrl-C -- query aborted.
ERROR 1317 (70100): Query execution was interrupted


SESSION_B>commit;
Query OK, 0 rows affected (0.00 sec)


SESSION_A>select * from t5;
+------+
| id   |
+------+
|    1 |
|    4 |
|    7 |
|   10 |
+------+
4 rows in set (0.00 sec)

SESSION_A>commit;
Query OK, 0 rows affected (0.00 sec)

SESSION_A>select * from t5;
+------+
| id   |
+------+
|    1 |
|    2 |
|    4 |
|    7 |
|   10 |
|   12 |
+------+
6 rows in set (0.00 sec)

當以當前讀模式select * from t5 where id=7 for update;獲取 id=7的資料時,產生了 Next-Key Lock,鎖住了4-10範圍和 id=7單個record
從而阻塞了 SESSION_B在這個範圍內插入資料，而在除此之外的範圍內是可以插入資料的。
在倒數第二個查詢中,因為 read view 的存在，避免了我們看到 2和12兩條資料，避免了幻讀
同時因為 Next-Key Lock 的存在,阻塞了其他回話插入資料，因此當前模式讀不會產生幻讀(select for update 是以當前讀模式獲取資料)

儘量使用唯一索引,因為唯一索引會把Next-Key Lock降級為Record Lock

建立表（primary key） 
([email protected]) [fandb]> create table t6(id int primary key); 
 Query OK, 0 rows affected (0.02 sec)

SESSION_A>insert into t6 values(1),(4),(7),(10); 
 Query OK, 4 rows affected (0.00 sec) 
 Records: 4 Duplicates: 0 Warnings: 0

開始實驗

SESSION_A>begin;
Query OK, 0 rows affected (0.00 sec)

SESSION_A>select * from t6;
+----+
| id |
+----+
|  1 |
|  4 |
|  7 |
| 10 |
+----+
4 rows in set (0.00 sec)

SESSION_A>select * from t6 where id=7 for update;
+----+
| id |
+----+
|  7 |
+----+
1 row in set (0.00 sec)


SESSION_B>begin;
Query OK, 0 rows affected (0.00 sec)

SESSION_B>insert into t6 values(5); --插入成功沒有阻塞
Query OK, 1 row affected (0.00 sec)

SESSION_B>insert into t6 values(8); --插入成功沒有阻塞
Query OK, 1 row affected (0.00 sec)

SESSION_B>commit;
Query OK, 0 rows affected (0.00 sec)

SESSION_A>select * from t6;
+----+
| id |
+----+
|  1 |
|  4 |
|  7 |
| 10 |
+----+
4 rows in set (0.00 sec)

SESSION_A>commit;
Query OK, 0 rows affected (0.00 sec)

SESSION_A>select * from t6;
+----+
| id |
+----+
|  1 |
|  4 |
|  5 |
|  7 |
|  8 |
| 10 |
+----+
6 rows in set (0.00 sec)

當 id 列有唯一索引,Next-Key Lock 會降級為 Records Lock