本文旨在糾正對幻讀的誤解：
首先回顧下事務隔離級別的定義：
- 讀未提交 READ-UNCOMMITTED | 0：存在髒讀，不可重複讀，幻讀的問題
- 讀已提交 READ-COMMITTED | 1：解決髒讀的問題，存在不可重複讀，幻讀的問題
- 可重複讀 REPEATABLE-READ | 2：解決髒讀，不可重複讀的問題，存在幻讀的問題，默認隔離級別，使用 MMVC機制 實現可重複讀
- 序列化 SERIALIZABLE | 3：解決髒讀，不可重複讀，幻讀，可保證事務安全，但完全串行執行，性能最低
幻讀會在 RU / RC / RR 級別下出現，SERIALIZABLE 則杜絕了幻讀，但 RU / RC 下還會存在髒讀，不可重複讀，故我們就以 RR 級別來研究幻讀，排除其他干擾。
注意：RR 級別下存在幻讀的可能，但也是可以使用對記錄手動加 X鎖 的方法消除幻讀。SERIALIZABLE 正是對所有事務都加 X鎖 才杜絕了幻讀，但很多場景下我們的業務sql並不會存在幻讀的風險。SERIALIZABLE 的一刀切雖然事務絕對安全，但性能會有很多不必要的損失。故可以在 RR 下根據業務需求決定是否加鎖，存在幻讀風險我們加鎖，不存在就不加鎖，事務安全與性能兼備，這也是 RR 作爲mysql默認隔是個事務離級別的原因，所以需要正確的理解幻讀。
幻讀錯誤的理解：
說幻讀是 事務A 執行兩次 select 操作得到不同的數據集，即 select 1 得到 10 條記錄，select 2 得到 11 條記錄。這其實並不是幻讀，這是不可重複讀的一種，只會在 R-U R-C 級別下出現，而在 mysql 默認的 RR 隔離級別是不會出現的。
幻讀：
並不是說兩次讀取獲取的結果集不同，幻讀側重的方面是某一次的 select 操作得到的結果所表徵的數據狀態無法支撐後續的業務操作。更爲具體一些：select 某記錄是否存在，不存在，準備插入此記錄，但執行 insert 時發現此記錄已存在，無法插入，此時就發生了幻讀。
可以使用兩個單獨會話進行驗證：
Session1：T1
SET session autocommit=0;
start transaction;
SELECT * FROM city WHERE id = 1;
INSERT INTO city VALUES(1,'000','000');
SELECT * FROM city WHERE id = 1;
COMMIT;
Session2：T2
SET session autocommit=0;
start transaction;
INSERT INTO city VALUES(1,'000','000');
COMMIT;
已經開啓事務，並關閉自動提交前提下：
第一步（T1）：SELECT * FROM city WHERE id = 1; （結果爲空）
第二步（T2）：INSERT INTO city VALUES(1,'000','000');
第三步（T1）：INSERT INTO city VALUES(1,'000','000'); （明明結果爲空，單卻插入失敗）
第四步（T1）：SELECT * FROM city WHERE id = 1;（結果仍然爲空！！！）
描述：此時對於事務T1來說，就發生了幻讀，明明讀取不到 id=1 的記錄，但是插入卻失敗
其實 RR 也是可以避免幻讀的，通過對 select 操作手動加 行X鎖（SELECT ... FOR UPDATE 這也正是 SERIALIZABLE 隔離級別下會隱式爲你做的事情），同時還需要知道，即便當前記錄不存在，比如 id = 1 是不存在的，當前事務也會獲得一把記錄鎖（因爲InnoDB的行鎖鎖定的是索引，故記錄實體存在與否沒關係，存在就加 行X鎖，不存在就加 next-key lock間隙X鎖），其他事務則無法插入此索引的記錄，故杜絕了幻讀。
在 SERIALIZABLE 隔離級別下，step1 執行時是會隱式的添加 行(X)鎖 / gap(X)鎖的，從而 step2 會被阻塞，step3 會正常執行，待 T1 提交後，T2 才能繼續執行（主鍵衝突執行失敗），對於 T1 來說業務是正確的，成功的阻塞扼殺了擾亂業務的T2，對於T1來說他前期讀取的結果是可以支撐其後續業務的。
所以 mysql 的幻讀並非什麼讀取兩次返回結果集不同，而是事務在插入事先檢測不存在的記錄時，驚奇的發現這些數據已經存在了，之前的檢測讀獲取到的數據如同鬼影一般。
這裏要靈活的理解讀取的意思，第一次select是讀取，第二次的 insert 其實也屬於隱式的讀取，只不過是在 mysql 的機制中讀取的，插入數據也是要先讀取一下有沒有主鍵衝突才能決定是否執行插入。
從事務的角度理解：不可重複讀側重表達 讀-讀，幻讀則是說 讀-寫，用寫來證實讀的是鬼影。
RR級別下防止幻讀
RR級別下只要對 SELECT 操作也手動加行（X）鎖即可類似 SERIALIZABLE 級別（它會對 SELECT 隱式加鎖）
SELECT id FROM city WHERE id = 1 FOR UPDATE;
如果 id = 1 的記錄存在則會被加行（X）鎖，如果不存在，則會加 next-lock key / gap 鎖（範圍行鎖），即記錄存在與否，mysql 都會對記錄應該對應的索引加鎖，其他事務會被阻塞。
補充：
InnoDB的行鎖鎖定的是索引，而不是記錄本身，這一點也需要有清晰的認識，故某索引相同的記錄都會被加鎖，會造成索引競爭，這就需要我們嚴格設計業務sql，儘可能的使用主鍵或唯一索引對記錄加鎖。索引映射的記錄如果存在，加行鎖，如果不存在，則會加 next-key lock / gap 鎖 / 間隙鎖，故InnoDB可以實現事務對某記錄的預先佔用，如果記錄存在，它就是本事務的，如果記錄不存在，那它也將是本是無的，只要本是無還在，其他事務就別想佔有它。