之前我也提到過，MySQL InnoDB 引擎的默認隔離級別雖然是「可重復讀」，但是它很大程度上避免幻讀現(xiàn)象（并不是完全解決了），解決的方案有兩種：

• 針對快照讀（普通 select 語句），是通過 MVCC 方式解決了幻讀，因為可重復讀隔離級別下，事務執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務啟動時看到的數(shù)據(jù)是一致的，即使中途有其他事務插入了一條數(shù)據(jù)，是查詢不出來這條數(shù)據(jù)的，所以就很好了避免幻讀問題。
• 針對當前讀（select ... for update 等語句），是通過 next-key lock（記錄鎖+間隙鎖）方式解決了幻讀，因為當執(zhí)行 select ... for update 語句的時候，會加上 next-key lock，如果有其他事務在 next-key lock 鎖范圍內插入了一條記錄，那么這個插入語句就會被阻塞，無法成功插入，所以就很好了避免幻讀問題。

這次，我會舉例兩個實驗場景來說明 MySQL InnoDB 引擎的可重復讀隔離級別發(fā)生幻讀的問題。

好了，發(fā)車！

什么是幻讀？

首先來看看 MySQL 文檔是怎么定義幻讀（Phantom Read）的:

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

翻譯：當同一個查詢在不同的時間產(chǎn)生不同的結果集時，事務中就會出現(xiàn)所謂的幻象問題。例如，如果 SELECT 執(zhí)行了兩次，但第二次返回了第一次沒有返回的行，則該行是“幻像”行。

舉個例子，假設一個事務在 T1 時刻和 T2 時刻分別執(zhí)行了下面查詢語句，途中沒有執(zhí)行其他任何語句：

SELECT * FROM t_test WHERE id > 100;

只要 T1 和 T2 時刻執(zhí)行產(chǎn)生的結果集是不相同的，那就發(fā)生了幻讀的問題，比如：

• T1 時間執(zhí)行的結果是有 5 條行記錄，而 T2 時間執(zhí)行的結果是有 6 條行記錄，那就發(fā)生了幻讀的問題。
• T1 時間執(zhí)行的結果是有 5 條行記錄，而 T2 時間執(zhí)行的結果是有 4 條行記錄，也是發(fā)生了幻讀的問題。

隔離級別

當多個事務并發(fā)執(zhí)行時可能會遇到「臟讀、不可重復讀、幻讀」的現(xiàn)象，這些現(xiàn)象會對事務的一致性產(chǎn)生不同程序的影響。

• 臟讀：讀到其他事務未提交的數(shù)據(jù)；
• 不可重復讀：前后讀取的數(shù)據(jù)不一致；
• 幻讀：前后讀取的記錄數(shù)量不一致。

這三個現(xiàn)象的嚴重性排序如下：

SQL 標準提出了四種隔離級別來規(guī)避這些現(xiàn)象，隔離級別越高，性能效率就越低，這四個隔離級別如下：

• 讀未提交（read uncommitted），指一個事務還沒提交時，它做的變更就能被其他事務看到；
• 讀提交（read committed），指一個事務提交之后，它做的變更才能被其他事務看到；
• 可重復讀（repeatable read），指一個事務執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務啟動時看到的數(shù)據(jù)是一致的，MySQL InnoDB 引擎的默認隔離級別；
• 串行化（serializable ）；會對記錄加上讀寫鎖，在多個事務對這條記錄進行讀寫操作時，如果發(fā)生了讀寫沖突的時候，后訪問的事務必須等前一個事務執(zhí)行完成，才能繼續(xù)執(zhí)行；

針對不同的隔離級別，并發(fā)事務時可能發(fā)生的現(xiàn)象也會不同。

也就是說：

• 在「讀未提交」隔離級別下，可能發(fā)生臟讀、不可重復讀和幻讀現(xiàn)象；
• 在「讀提交」隔離級別下，可能發(fā)生不可重復讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象；
• 在「可重復讀」隔離級別下，可能發(fā)生幻讀現(xiàn)象，但是不可能臟讀和不可重復讀現(xiàn)象；
• 在「串行化」隔離級別下，臟讀、不可重復讀和幻讀現(xiàn)象都不可能會發(fā)生。

所以，要解決臟讀現(xiàn)象，就要升級到「讀提交」以上的隔離級別；要解決不可重復讀現(xiàn)象，就要升級到「可重復讀」的隔離級別，要解決幻讀現(xiàn)象不建議將隔離級別升級到「串行化」。

不同的數(shù)據(jù)庫廠商對 SQL 標準中規(guī)定的 4 種隔離級別的支持不一樣，有的數(shù)據(jù)庫只實現(xiàn)了其中幾種隔離級別，我們討論的 MySQL 雖然支持 4 種隔離級別，但是與SQL 標準中規(guī)定的各級隔離級別允許發(fā)生的現(xiàn)象卻有些出入。

MySQL 在「可重復讀」隔離級別下，可以很大程度上避免幻讀現(xiàn)象的發(fā)生（注意是很大程度避免，并不是徹底避免），所以 MySQL 并不會使用「串行化」隔離級別來避免幻讀現(xiàn)象的發(fā)生，因為使用「串行化」隔離級別會影響性能。

MySQL InnoDB 引擎的默認隔離級別雖然是「可重復讀」，但是它很大程度上避免幻讀現(xiàn)象（并不是完全解決了），解決的方案有兩種：

• 針對快照讀（普通 select 語句），是通過 MVCC 方式解決了幻讀，因為可重復讀隔離級別下，事務執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務啟動時看到的數(shù)據(jù)是一致的，即使中途有其他事務插入了一條數(shù)據(jù)，是查詢不出來這條數(shù)據(jù)的，所以就很好了避免幻讀問題。
• 針對當前讀（select ... for update 等語句），是通過 next-key lock（記錄鎖+間隙鎖）方式解決了幻讀，因為當執(zhí)行 select ... for update 語句的時候，會加上 next-key lock，如果有其他事務在 next-key lock 鎖范圍內插入了一條記錄，那么這個插入語句就會被阻塞，無法成功插入，所以就很好了避免幻讀問題。

快照讀是如何避免幻讀的？

可重復讀隔離級是由 MVCC（多版本并發(fā)控制）實現(xiàn)的，實現(xiàn)的方式是啟動事務后，在執(zhí)行第一個查詢語句后，會創(chuàng)建一個 Read View，后續(xù)的查詢語句利用這個 Read View，通過這個  Read View 就可以在 undo log 版本鏈找到事務開始時的數(shù)據(jù)，所以事務過程中每次查詢的數(shù)據(jù)都是一樣的，即使中途有其他事務插入了新紀錄，是查詢不出來這條數(shù)據(jù)的，所以就很好了避免幻讀問題。

做個實驗，數(shù)據(jù)庫表 t_stu 如下，其中 id 為主鍵。

然后在可重復讀隔離級別下，有兩個事務的執(zhí)行順序如下：

從這個實驗結果可以看到，即使事務 B 中途插入了一條記錄，事務 A 前后兩次查詢的結果集都是一樣的，并沒有出現(xiàn)所謂的幻讀現(xiàn)象。

當前讀是如何避免幻讀的？

MySQL 里除了普通查詢是快照讀，其他都是當前讀，比如 update、insert、delete，這些語句執(zhí)行前都會查詢最新版本的數(shù)據(jù)，然后再做進一步的操作。

這很好理解，假設你要 update 一個記錄，另一個事務已經(jīng) delete 這條記錄并且提交事務了，這樣不是會產(chǎn)生沖突嗎，所以 update 的時候肯定要知道最新的數(shù)據(jù)。

另外，select ... for update這種查詢語句是當前讀，每次執(zhí)行的時候都是讀取最新的數(shù)據(jù)。

# 事務 A mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t_stu where id = 5;
Empty set (0.01 sec)

# 事務 B mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t_stu values(5, '小美', 18);
Query OK, 1 row affected (0.00 sec)

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

# 事務 A mysql> update t_stu set name = '小林coding' where id = 5;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from t_stu where id = 5;
+----+--------------+------+ | id | name         | age  |
+----+--------------+------+ |  5 | 小林coding   |   18 |
+----+--------------+------+ 1 row in set (0.00 sec)