mysql 幻讀的詳解、實例及解決辦法

髒讀/不可重複讀的概念都比較容易理解和掌握，這裏不在討論

事務隔離級別（tx_isolation）

mysql 有四級事務隔離級別 每一個級別都有字符或數字編號

讀未提交 READ-UNCOMMITTED | 0：存在髒讀，不可重複讀，幻讀的問題

讀已提交 READ-COMMITTED | 1：解決髒讀的問題，存在不可重複讀，幻讀的問題

可重複讀 REPEATABLE-READ | 2：解決髒讀，不可重複讀的問題，存在幻讀的問題，默認隔離級別，使用 MMVC機制 實現可重複讀

序列化 SERIALIZABLE | 3：解決髒讀，不可重複讀，幻讀，可保證事務安全，但徹底串行執行，性能最低

咱們能夠經過如下命令 查看/設置 全局/會話 的事務隔離級別

mysql> SELECT @@global.tx_isolation, @@tx_isolation;
+-----------------------+------------------+
| @@global.tx_isolation | @@tx_isolation   |
+-----------------------+------------------+
| REPEATABLE-READ       | READ-UNCOMMITTED |
+-----------------------+------------------+
1 row in set (0.00 sec)

# 設定全局的隔離級別 設定會話 global 替換爲 session 便可 把set語法溫習一下
# SET [GLOABL] config_name = 'foobar';
# SET @@[session|global].config_name = 'foobar';
# SELECT @@[global.]config_name;

SET @@gloabl.tx_isolation = 0;
SET @@gloabl.tx_isolation = 'READ-UNCOMMITTED';

SET @@gloabl.tx_isolation = 1;
SET @@gloabl.tx_isolation = 'READ-COMMITTED';

SET @@gloabl.tx_isolation = 2;
SET @@gloabl.tx_isolation = 'REPEATABLE-READ';

SET @@gloabl.tx_isolation = 3;
SET @@gloabl.tx_isolation = 'SERIALIZABLE';

幻讀

首先咱們要搞明白何謂幻讀，目前網上的衆多解釋幻讀的博文我的感受仔細設想一下就能找出推翻的例子，就像博文把 非阻塞IO 等同爲 異步IO，而後好多文章都紛紛借用，其實這倆貨是徹底不一樣，非阻塞IO 是 同步IO 中的一種模式，並不是 異步IO。錯誤的觀點都被大衆認同的 "正確化" 了，扯遠了，迴歸主題。

幻讀會在 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 時發現此記錄已存在，沒法插入，此時就發生了幻讀。

這裏給出 mysql 幻讀的比較形象的場景（借用我在知乎上的回答）：

table users: id primary key

事務T1

事務T2

step1 T1: SELECT * FROM `users` WHERE `id` = 1;
step2 T2: INSERT INTO `users` VALUES (1, 'big cat');
step3 T1: INSERT INTO `users` VALUES (1, 'big cat');
step4 T1: SELECT * FROM `users` WHERE `id` = 1;

T1 ：主事務，檢測表中是否有 id 爲 1 的記錄，沒有則插入，這是咱們指望的正常業務邏輯。

T2 ：干擾事務，目的在於擾亂 T1 的正常的事務執行。

在 RR 隔離級別下，step一、step2 是會正常執行的，step3 則會報錯主鍵衝突，對於 T1 的業務來講是執行失敗的，這裏 T1 就是發生了幻讀，由於 T1 在 step1 中讀取的數據狀態並不能支撐後續的業務操做，T1：「見鬼了，我剛纔讀到的結果應該能夠支持我這樣操做纔對啊，爲何如今不能夠」。T1 不敢相信的又執行了 step4，發現和 setp1 讀取的結果是同樣的（RR下的 MMVC機制）。此時，幻讀無疑已經發生，T1 不管讀取多少次，都查不到 id = 1 的記錄，但它的確沒法插入這條他經過讀取來認定不存在的記錄（此數據已被T2插入），對於 T1 來講，它幻讀了。

其實 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 隱式加鎖），即你們熟知的：

# 這裏須要用 X鎖， 用 LOCK IN SHARE MODE 拿到 S鎖 後咱們沒辦法作 寫操做
SELECT `id` FROM `users` WHERE `id` = 1 FOR UPDATE;

若是 id = 1 的記錄存在則會被加行（X）鎖，若是不存在，則會加 next-lock key / gap 鎖（範圍行鎖），即記錄存在與否，mysql 都會對記錄應該對應的索引加鎖，其餘事務是沒法再得到作操做的。

這裏咱們就展現下 id = 1 的記錄不存在的場景，FOR UPDATE 也會對此 「記錄」 加鎖，要明白，InnoDB 的行鎖（gap鎖是範圍行鎖，同樣的）鎖定的是記錄所對應的索引，而不是記錄自己，因此記錄存在與否均可以對索引加鎖。

id = 1 的記錄不存在，開始執行事務：
step1: T1 查詢 id = 1 的記錄並對其加 X鎖
step2: T2 插入 id = 1 的記錄，被阻塞
step3: T1 插入 id = 1 的記錄，成功執行（T2 依然被阻塞中），T1 提交（T2 喚醒但主鍵衝突執行錯誤）

T1事務符合業務需求成功執行，T2干擾T1失敗。

SERIALIZABLE級別杜絕幻讀

在此級別下，咱們便不須要對 SELECT 操做顯式加鎖，InnoDB會自動加鎖，事務安全，但性能很低

step1: T1 查詢 id = 2 的記錄，InnoDB 會隱式的對齊加 X鎖
step2: T2 插入 id = 2 的記錄，被阻塞
step3: T1 插入 id = 2 的記錄，成功執行（T2 依然被阻塞中）
step4: T1 成功提交（T2 此時喚醒但主鍵衝突執行錯誤）

T1事務符合業務需求成功執行，T2干擾T1失敗。

總結

RR 級別做爲 mysql 事務默認隔離級別，是事務安全與性能的折中，可能也符合二八定律（20%的事務存在幻讀的可能，80%的事務沒有幻讀的風險），咱們在正確認識幻讀後，即可以根據場景靈活的防止幻讀的發生。

SERIALIZABLE 級別則是悲觀的認爲幻讀時刻都會發生，故會自動的隱式的對事務所需資源加排它鎖，其餘事務訪問此資源會被阻塞等待，故事務是安全的，但須要認真考慮性能。

InnoDB的行鎖鎖定的是索引，而不是記錄自己，這一點也須要有清晰的認識，故某索引相同的記錄都會被加鎖，會形成索引競爭，這就須要咱們嚴格設計業務sql，儘量的使用主鍵或惟一索引對記錄加鎖。索引映射的記錄若是存在，加行鎖，若是不存在，則會加 next-key lock / gap 鎖 / 間隙鎖，故InnoDB能夠實現事務對某記錄的預先佔用，若是記錄存在，它就是本事務的，若是記錄不存在，那它也將是本是無的，只要本是無還在，其餘事務就別想佔有它。