????????我們來詳細地聊一聊 MySQL InnoDB 中的“幻讀”（Phantom Read）問題。這是一個在數據庫事務隔離中非常核心且有時令人困惑的概念。
我會從定義、例子、原因以及解決方案幾個方面來徹底講清楚。
1. 什么是幻讀？
官方定義：幻讀指的是在一個事務內，相同的查詢在不同時間執行，返回了不同數量的行。
這聽起來和“不可重復讀”很像，但它們有關鍵區別：
-
不可重復讀 (Non-Repeatable Read)：側重于同一行的數據內容被修改或刪除。（例如：你第二次查詢時，某行的薪水從10000變成了12000）。
-
幻讀 (Phantom Read)：側重于新的行被插入（或刪除），導致結果集的行數發生了變化。（針對結果集的數量變化，例如：你第一次查詢有10條記錄，第二次查詢卻冒出了11條）。
簡單比喻：
-
不可重復讀：你碗里的一塊紅燒肉被別人咬了一口（數據內容變了）。
-
幻讀：你正準備夾碗里最后一塊紅燒肉時，別人突然又往碗里加了一塊新的肉（數據行數變了）。
2. 幻讀發生的場景與例子
幻讀發生的根本原因是：在“可重復讀（REPEATABLE READ）”及以下隔離級別中，普通的一致性讀（快照讀）無法阻止其他事務插入新的、滿足當前查詢條件的數據。
我們來看一個經典的例子。
表結構：
CREATE TABLE `employee` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(50) NOT NULL,`salary` int(11) DEFAULT NULL,PRIMARY KEY (`id`),KEY `idx_salary` (`salary`)
) ENGINE=InnoDB;INSERT INTO `employee` (`name`, `salary`) VALUES
('Alice', 8000),
('Bob', 9000),
('Charlie', 10000);時間線：
| 時間 | 事務A (隔離級別：RR) | 事務B |
|---|---|---|
| T1 | START TRANSACTION; | |
| T2 | SELECT * FROM employee WHERE salary > 8000;結果： Bob, 9000 Charlie, 10000 (2 rows) | START TRANSACTION; |
| T3 | INSERT INTO employee (name, salary) VALUES ('David', 9500);COMMIT;?<!-- 事務B提交 --> | |
| T4 | SELECT * FROM employee WHERE salary > 8000;結果： Bob, 9000 Charlie, 10000 (仍然是2 rows！) （這里沒有幻讀，因為RR級別通過MVCC提供了快照） | |
| T5 | UPDATE employee SET salary = 8888 WHERE salary > 8000;（注意：這個更新操作是當前讀，會看到事務B已提交的修改） | |
| T6 | SELECT * FROM employee WHERE salary > 8000;結果： Bob, 8888 Charlie, 8888 David, 8888 (3 rows! 幻讀出現了！) |
例子分析：
-
T2時刻：事務A第一次查詢，得到2條記錄。
-
T4時刻：事務A第二次普通查詢（快照讀）。由于InnoDB的MVCC（多版本并發控制）機制，它會讀取事務開始時的數據快照，所以看不到事務B新插入的?
David(9500)。此時還沒有幻讀。 -
T5時刻：關鍵點來了！事務A執行了一個UPDATE操作。UPDATE/DELETE/INSERT 這類寫操作會使用“當前讀”（Current Read），它會讀取數據庫中最新的、已提交的數據。因此，它看到了事務B插入的?
David(9500)?這條記錄，并將其薪水也更新為8888。 -
T6時刻：事務A再次查詢。因為之前的UPDATE操作屬于當前事務的修改，所以MVCC規則允許它看到自己的修改。于是，它神奇地看到了三條記錄！幻讀就在這一刻發生了。
這個例子展示了InnoDB中幻讀最典型的特征：即使是在默認的RR隔離級別下，先快照讀，再當前讀進行寫操作，可能會意外地影響新插入的行，從而導致數據不一致。
3. 解決方案：Next-Key Lock 鎖機制
InnoDB引擎為了解決幻讀問題，在“可重復讀（REPEATABLE READ）”隔離級別下就引入了一種叫做?Next-Key Lock?的鎖機制。它實際上是?記錄鎖（Record Lock）?和?間隙鎖（Gap Lock）?的結合。
-
記錄鎖 (Record Lock)：鎖住索引上的某一條具體記錄。
-
間隙鎖 (Gap Lock)：鎖住索引記錄之間的“間隙”，防止在這個間隙內插入新的數據。它是一個左開右開的區間?
(a, b)。 -
臨鍵鎖 (Next-Key Lock)：是記錄鎖 + 間隙鎖的結合。它鎖住一條記錄和它前面的間隙。它是一個左開右閉的區間?
(a, b]。
如何解決幻讀？
在上面的例子中，如果事務A在第一次查詢時，就對?salary > 8000?這個條件加上了鎖，那么事務B的插入操作就會被阻塞，從而杜絕幻讀。
讓我們重演時間線，但這次事務A加鎖查詢：
| 時間 | 事務A (加鎖查詢) | 事務B |
|---|---|---|
| T1 | START TRANSACTION; | |
| T2 | SELECT * FROM employee WHERE salary > 8000 FOR UPDATE;（FOR UPDATE 會給查詢結果加Next-Key Lock） 結果：2 rows | START TRANSACTION; |
| T3 | INSERT INTO employee (name, salary) VALUES ('David', 9500);（這條語句會被阻塞，一直等待事務A釋放鎖！） | |
| T4 | SELECT ... FOR UPDATE;?（再次查詢，結果一致） | ...（阻塞中）... |
| T5 | COMMIT;?（提交事務，釋放鎖） | ...（阻塞結束）... |
| T6 | （此時事務B才能成功插入） |
發生了什么？
當事務A執行?SELECT ... FOR UPDATE?時，InnoDB會為其加Next-Key Lock。假設?salary?上有二級索引?idx_salary，它可能會鎖住以下區間：
-
鎖住?
(8000, 9000]?這個Next-Key Lock（鎖住9000這條記錄和它前面的間隙）。 -
鎖住?
(9000, 10000]?這個Next-Key Lock（鎖住10000這條記錄和它前面的間隙）。 -
鎖住?
(10000, +∞]?這個Next-Key Lock（鎖住正無窮的上界）。
事務B試圖插入?salary = 9500?的記錄，這個值落在被事務A鎖住的?(9000, 10000]?間隙內，因此插入操作會被阻塞，直到事務A提交釋放鎖。這樣就徹底防止了幻讀的發生。
總結與最佳實踐
| 特性 | 說明 |
|---|---|
| 幻讀本質 | 同一事務內，兩次查詢結果集行數不一致， due to 其他事務的插入或刪除操作。 |
| InnoDB的默認防御 | 在REPEATABLE READ隔離級別下，InnoDB通過?Next-Key Lock?機制來防止幻讀。 |
| 何時會發生幻讀 | 即使是在RR級別下，如果你只是進行普通的快照讀（SELECT），然后基于此進行當前讀的寫操作（UPDATE/INSERT/DELETE），仍然可能遇到幻讀。快照讀不加鎖是根源。 |
| 徹底解決方法 | 在需要絕對保證數據一致性的關鍵操作中，使用?加鎖讀： 1.? SELECT ... FOR UPDATE;?（加寫鎖，阻塞其他事務的寫和加鎖讀）2.? SELECT ... LOCK IN SHARE MODE;?（加讀鎖，阻塞其他事務的寫）這些語句會在符合條件的索引上加Next-Key Lock，從而阻止其他事務在鎖定區間內插入新數據。 |
| 終極方案 | 將事務隔離級別提升至?SERIALIZABLE。在這個級別下，所有的讀操作都會默認加上類似?LOCK IN SHARE MODE?的鎖，幻讀自然不會發生，但這是以犧牲并發性能為代價的，一般不建議使用。 |
核心要點：MySQL InnoDB 在 RR 級別下已經通過 Next-Key Lock 很大程度上解決了幻讀問題。但你需要清楚地知道，只有在你的查詢語句確實需要加鎖（例如使用了?FOR UPDATE）或者涉及寫操作時，Next-Key Lock 才會生效。單純的快照讀是無法完全避免幻讀的潛在影響的。
推薦一個非常好用的工具集合：在線工具集合 - 您的開發助手
