一：准備
- 為了深入了解幻讀，准備數據。
-
-
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);
-
- 思考
- 下面的語句是什么時候加鎖，什么時候釋放鎖的呢？
-
-
begin; select * from t where c=5 for update; commit;
-
- InnoDB 的默認事務隔離級別是可重復讀，所以下面的問題，都是設定在可重復讀隔離級別下。
- 其他隔離級別會在末尾講述。
二：什么是幻讀？
- 幻讀（讀已提交隔離級別下的表現）
- 
- 問題解讀
- 可以看到，session A 里執行了三次查詢，分別是 Q1、Q2 和 Q3。它們的 SQL 語句相同，都是 select * from t where d=5 for update。
- 這個語句的意思你應該很清楚了，查所有 d=5 的行，而且使用的是當前讀，並且加上寫鎖。
- 紅字中是每個事務讀到的結果，會發現，每次返回的記錄都不同。
- 幻讀定義
- 也就是說，幻讀指的是一個事務在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。
三：幻讀存在的問題？
- 語意問題
- session A 在 T1 時刻就聲明了，“我要把所有 d=5 的行鎖住，不准別的事務進行讀寫操作”。
- 而實際上，這個語義被破壞了。
- 數據一致性問題
- 這個一致性，不止是數據庫內部數據狀態在此刻的一致性，還包含了數據和日志在邏輯上的一致性。
- 那我把經過的記錄都加上鎖，能解決這個問題了么？
- 
- 可以看出，即使對所有經過的記錄加鎖，也不能阻止 session A 讀到多余的記錄。
- 原因很簡單。在 T3 時刻，我們給所有行加鎖的時候，id=1 這一行還不存在，不存在也就加不上鎖。
- 也就是說，即使把所有的記錄都加上鎖，還是阻止不了新插入的記錄。
- 所以，InnoDB為了解決幻讀，設計出了一種新鎖。
四：如何解決幻讀？（也是可重復讀隔離級別的實現原理）
- 使用間隙鎖
- 現在你知道了，產生幻讀的原因是，行鎖只能鎖住行，但是新插入記錄這個動作，要更新的是記錄之間的“間隙”。
- 因此，為了解決幻讀問題，InnoDB 只好引入新的鎖，也就是間隙鎖 (Gap Lock)。
- 顧名思義，間隙鎖，鎖的就是兩個值之間的空隙。
- 比如文章開頭的表 t，初始化插入了 6 個記錄，這就產生了 7 個間隙。
- 
- 這樣，當你執行 select * from t where d=5 for update 的時候，就不止是給數據庫中已有的 6 個記錄加上了行鎖，還同時加了 7 個間隙鎖。
- 這樣就確保了無法再插入新的記錄。
- 也就是說這時候，在一行行掃描的過程中，不僅將給行加上了行鎖，還給行兩邊的空隙，也加上了間隙鎖。
- 現在你知道了，數據行是可以加上鎖的實體，數據行之間的間隙，也是可以加上鎖的實體。
- 但是間隙鎖跟我們之前碰到過的鎖都不太一樣。
- 間隙鎖和行鎖
- 行鎖的沖突關系為
- 
- 也就是說，跟行鎖有沖突關系的是“另外一個行鎖”。
- 間隙鎖的沖突關系為
- 跟間隙鎖存在沖突關系的，是“往這個間隙中插入一個記錄”這個操作。
- 通過下面的死鎖來解釋這個鎖關系
- 
- 間隙鎖死鎖解釋
- session A 執行 select … for update 語句，由於 id=9 這一行並不存在，因此會加上間隙鎖 (5,10);
- session B 執行 select … for update 語句，同樣會加上間隙鎖 (5,10)，間隙鎖之間不會沖突，因此這個語句可以執行成功；
- session B 試圖插入一行 (9,9,9)，被 session A 的間隙鎖擋住了，只好進入等待；
- session A 試圖插入一行 (9,9,9)，被 session B 的間隙鎖擋住了。
- 至此，兩個 session 進入互相等待狀態，形成死鎖。
- 當然，InnoDB 的死鎖檢測馬上就發現了這對死鎖關系，讓 session A 的 insert 語句報錯返回了。
- 理解了間隙鎖的沖突關系后
- 通過間隙鎖和 next-key lock 的引入，幫我們解決了幻讀的問題，但是可能會導致同樣的語句鎖住更大的范圍，這其實是影響了並發度的。
五：回頭看 問題 select * from t where d=5 for update; 的鎖？
- 前提是在該字段有索引的情況下
- 因為 InnoDB 的加鎖是根據索引加鎖的，在沒有索引的字段上執行，會導致鎖全表。
- 在讀提交的隔離級別下
- 讀提交隔離級別下，在語句執行完成后，是只有行鎖的。
- 而且語句執行完成后，InnoDB 就會把不滿足條件的行行鎖去掉。
- 在可重復讀的隔離級別下
- 由於間隙鎖，會鎖住 0-5/5-10 兩個間隙范圍。