CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `c` (`c`)
) ENGINE=InnoDB;
insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);
什么是幻讀
在可重復讀的隔離級別下，我們如果只對id=5（也就是d=5由于d上沒有索引，所以會走主鍵索引樹）加行鎖，我們可以分析以下SessionA會出現什么情況：
- Q1查詢只會返回id=5這一行，也就是(5,5,5)
- T2時刻Session B把id為0這一行的d值改成5，因此Q2查詢查出來的是id=0和id=5的這兩行(0,0,5)，(5,5,5)
- T4時刻，Session C插入一行(1,1,5)，因此Q3查詢查出來的是id=0、1、5的這三行(0,0,5)，(1,1,5)，(5,5,5)
注意：上述Session A中查詢都是當前讀，關于當前讀可以見MySQL MVCC(多版本控制)這篇文章。
Q3讀到id=1這一行的現象成為幻讀。幻讀是指一個事務在前后兩次查詢同一個范圍的數據的時候，后一次查詢查到了第一次查詢沒有查到的行。
在可重復隔離級別下，普通的查詢時快照讀，是無法看到別的事務插入的數據的，只有當前讀才會出現幻讀。
幻讀有什么問題？
- 語義上帶來了破壞。
Session A在T1時刻就聲明我要把所有d=5的行鎖住，不允許別的事務進行讀寫操作，但是實際上別的事務可以破壞這個聲明。
- 數據一致性上會有問題。
- 經過T1時刻，id=5這一行變成(5,5,100)，當然這個結果最終是在T6時刻進行提交
- 經過T2時刻，id=0這一行變成了(0,5,5)
- 經過T4時刻，表里面新生成了一行(1,5,5)
數據似乎很正常沒有什么問題，但是如果你去分析binlog就會發現有問題了：
- T2時刻，Session B事務提交，寫入兩條語句；
- T4時刻，Session C事務提交，寫入兩條語句；
- T6時刻，Session A事務提交，寫入update t set d=100 where d=5這條語句
上述形成的binlog如下：
-- binlog的模式是statement;
update t set d=5 where id=0; /*(0,0,5)*/
update t set c=5 where id=0; /*(0,5,5)*/
insert into t values(1,1,5); /*(1,1,5)*/
update t set c=5 where id=1; /*(1,5,5)*/
update t set d=100 where d=5;/*所有d=5的行，d改成100*/
這個binlog如果被拿到備庫執行或者用來克隆一個數據庫，這三行的結果會變成(0,5,100)、(1,5,100)和(5,5,100)，此時id=0和id=1這兩行就出現了數據不一致。
如何解決幻讀？
產生幻讀的原因就是行鎖只能鎖住行，插入動作更新的是記錄之間的間隙。因此為了解決幻讀問題，InnoDB引入了間隙鎖。
什么是間隙鎖？
在文章開始的時候我們插入了6條數據，這就會產生7個間隙，如下：
- (-∞, 0)
- (0, 5)
- (5, 10)
- (10, 15)
- (15, 20)
- (20, 25)
- (25, +∞)
當我們在執行select * from t where d=5 for update的時候，除了給數據庫已有的行加行鎖以外，還會對7個間隙加鎖，這樣確保了沒有拿到鎖的事務無法插入新的記錄。
間隙鎖之間沒有沖突，跟間隙鎖沖突的是往這個間隙中插入一個記錄的操作。
什么是next-key lock？
間隙鎖和和行鎖合稱next-key lock，每個next-key lock都是前開后閉區間。
select * from t where d=5 for update在執行的時候將形成7個next-key lock：
- (-∞, 0]
- (0, 5]
- (5, 10]
- (10, 15]
- (15, 20]
- (20, 25]
- (25, +∞]
其中+∞在這里是InnoDB給每個索引加了一個不存在的最大值。
間隙鎖導致死鎖？
Session B的insert會被阻塞，Session A在執行insert的時候會檢測到死鎖，如下圖：
- Session A執行select for update，由于id=8這一行并不存在，因此會加上間隙鎖(5,10)
- Session Bz執行select for update同樣也會加上間隙鎖，間隙鎖之間并不沖突，因此可以執行成功
- Session B嘗試插入(9,9,9)，被Session A的間隙鎖阻塞，只好進入等待
- Session A嘗試插入(9,9,9)，被Session B的間隙鎖阻塞
此時兩個Session形成死鎖等待，InnoDB的死鎖檢測發現死鎖關系，讓Session A的insert 語句報錯返回。
間隙鎖是在可重復讀隔離級別下才會生效，如果將隔離級別設置為讀提交，就不會有間隙鎖了，但是同時需要解決數據和日志不一致的問題（需要把binlog格式設置為ROW）。
