[[437528]]

本文轉載自微信公眾號「飛天小牛肉」，作者飛天小牛肉 。轉載本文請聯系飛天小牛肉公眾號。

所謂幻讀，即一個事務在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行，這個回答估計大伙兒已經背爛了，但是它具體有什么后果呢?為什么會被 MySQL 單獨拎出來解決呢?MySQL 又是如何解決的呢?

當前讀和快照讀

在了解幻讀以及 MySQL 是如何解決幻讀這個問題前，我們需要知道，什么是當前讀、什么是快照讀。

• 快照讀：讀取快照中的數據，不需要進行加鎖。看到快照這兩個字，各位肯定馬上就想到 MVCC 了，是這樣，MVCC 作用于讀取已提交和可重復讀(默認)這兩個隔離級別，這倆隔離級別下的普通 select 操作就是快照讀
• 當前讀：讀取的是最新版本的數據, 并且對讀取的記錄加鎖, 阻塞其他事務同時改動相同記錄，避免出現安全問題。

除了讀取已提交和可重復讀這倆隔離級別下的普通 select 操作，其余操作都是當前讀：

select...lock in share mode (共享讀鎖) 
select...for update 
update, delete, insert 

舉個例子，來直觀感受下快照讀和當前讀，以可重復讀隔離級別為例，假設我們目前有一張 user 表，有如下的數據：

開啟兩個事務：

事務 1 先來個快照讀看看：

沒毛病，很正常。

事務 2 修改 age = 99，然后提交：

你猜，這時候，事務 1 快照讀出來的數據應該是多少?

是的，仍然是舊數據：

那事務 1 “當前讀” 出來的數據肯定是最新的了：

幻讀到底有什么問題

所謂幻讀，即一個事務在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。

在可重復讀隔離級別下，普通的查詢是快照讀，當前事務是不會看到別的事務插入的數據的。因此，幻讀問題在 “當前讀” 下才會出現。

也有很多的文章說用 MVCC 來解決 "快照讀" 下的幻讀問題，我覺得沒必要糾結吧，甚至可能面試官更可能愿意聽到 MVCC 的原理。

不過，話說回來，沒有 MVCC 機制，哪來快照讀這個東西?

那么，幻讀到底有什么問題?它具體有什么后果呢?

不多廢話，直接上例子：

我們有一張表 user(id, username, age)，已經有兩條數據 (1, "Jack", 20), (2, "Tom", 18)

有如下三個事務：

眾所周知，select for update 語句會加行鎖，假設，注意這里是假設奧!!!假設事務 1 的 select * from user where name = 'Jack' for update 只在 id = 1 的這一行上加行鎖

可以看到，事務 1 執行了三次查詢，都是要查出 name = "Jack" 的記錄行。注意我們假設這里只在 name = 'Jack' 行上加行鎖

• 第一次查詢只返回了 id = 1 這一行
• 在第二次查詢之前，事務 2 把 id = 2 這一行的 name 值改成了 "Jack"，因此事務 1 第二次查詢的結果是 id = 1 和 id = 2 這兩行
• 在第三次查詢之前，事務 3 插入了一個 name = "Jack" 的新數據，因此事務 1 第三次查詢的結果是 id = 1、id = 2 以及 id = 3 這三行

顯然，第三次查詢讀到的 id = 3 這一行的現象，就是幻讀

但其實從邏輯上來說，這似乎是沒有問題的。

因為這三個查詢都是加了 for update，都是當前讀。而當前讀的規則，就是要能讀到所有已經提交的記錄的最新值，所以第二次查詢和第三次查詢就是應該看到事務 2 和事務 3 的操作效果。

那么，幻讀到底有啥問題?

首先是語義上的。事務 1 在第一次查詢的時候就聲明了，我要把所有 name = "Jack" 的行鎖住，拒絕別的事務對 name = "Jack" 的行進行讀寫操作。

但是，實際上，這個語義被破壞了，舉個例子，我再往事務 2 里加一條 SQL 語句(黃色框框)：

事務 2 的第二條語句的意思是 "把 id = 2 這一行的 age 值改成了 40"，這行的 name 值是 "Jack"。

而在這之前，事務 1 只是給 id = 5 的這一行加了行鎖，并沒有給 id = 2 這行加鎖。所以，事務 2 是可以執行這條 update 語句的。

這樣，事務 2 先將 id = 2 的 name 改為 Jack，然后再將 age 改為 40，破壞了事務 1 對要把所有 "name = Jack 的行鎖住" 的聲明

其次，最重要的是，是數據一致性的問題。

眾所周知，加鎖是為了保證數據的一致性，這個一致性，不僅包括數據的一致性，還包括數據和日志的一致性，舉個例子：

給事務 1 再加上一條 SQL 語句(黃色框框)

我在上圖中圈出了四個時刻， T1 T2 T3 和 T4，我們來分析下經過這四個時刻的數據庫狀態：

• 經過 T1 時刻，id = 1 這一行變成 (1, Tom, 20)，注意這是在 T4 才正式提交的
• 經過 T2 時刻，id = 2 這一行變成 (2, Jack, 40)
• 經過 T3 時刻，表里面多了一行 (3, Jack, 30)

再來看看這時候 binlog 日志里面的內容，binlog 就是記錄下我們做了哪些操作嘛：

T2 時刻，事務 2 提交，寫入了 2 條 update 語句;

update user set name = "Jack" where id = 2 
update user set age = "40" where id = 2 /*(2, Jack, 40)*/ 

T3 時刻，事務 3 提交，寫入了 1 條語句; 

insert into user values(3, "Jack", 30) /*(3, Jack, 30)*/ 

T4 時刻，事務 1 提交，binlog 中寫入了 update user set name = "Tom" where name = "Jack" 這條語句

update user set name = "Tom" where name = "Jack" 

就是說，把所有 name = Jack 的行，都給我改成 name = "Tom"

這樣，問題就來嘍，binlog 一般都是用于備庫同步主庫的對吧，這個 binlog 一執行，那豈不是原先 (2, Jack, 40) 和 (3, Jack, 30) 這兩行的 name 全都變成了 Tom。

也就是說，id = 2 和 id = 3 這兩行，發生了數據不一致。

注意!這個數據不一致到底是怎么發生的?是假設事務 1 的 select * from user where name = 'Jack' for update 只在 id = 1 的這一行上加行鎖導致的。

很顯然，分析到這里，我們已經明白，只鎖這一行是不合理的。那好辦，讓 select for update 把所有掃描到的行都給鎖住不就行了?

這樣，事務 2 在 T2 時刻就會被阻塞住，直到事務 1 在 T4 時刻 commit 釋放鎖。

由于 session A 把所有的行都加了寫鎖，所以 session B 在執行第一個 update 語句的時候就被鎖住了。需要等到 T6 時刻 session A 提交以后，session B 才能繼續執行。

But，這樣看似沒問題，是否真的沒問題呢?

來看 binlog，執行序列是這樣的：

事務 3: 
insert into user values(3, "Jack", 30) /*(3, Jack, 30)*/ 
 
事務 1: 
update user set name = "Tom" where name = "Jack" 
 
事務 2: 
update user set name = "Jack" where id = 2 
update user set age = "40" where id = 2 /*(2, Jack, 40)*/ 

可以看到，事務 2 的問題確實是解決了，Jack 保住了，仍然是 (2, Jack, 40)

但是!!!注意事務 3，在數據庫里面的結果是 (3, "Jack", 30)，而根據 binlog 的執行結果是 (3, Tom, 30)，也就是說幻讀的問題還是沒有解決。

那為什么我們已經把所有能夠掃描到的記錄都加上了鎖，還是阻止不了 id = 3 這一行的插入和更新呢?

很簡單。在我們給所有行加鎖的時候，id = 3 這一行還不存在，數據庫掃描不到，也就當然加不上鎖了。

這也是為什么幻讀問題會被單獨拿出來解決的原因，即使我們把所有的的記錄都加上鎖，還是阻止不了新插入的記錄。

MySQL 如何解決幻讀

現在你知道了，產生幻讀的原因是，行鎖只能鎖住行，但是新插入記錄這個動作，操作的是鎖住的行之間的 “間隙”。因此，為了解決幻讀問題，InnoDB 只好引入新的鎖，也就是間隙鎖 (Gap Lock)。

這樣，當你執行 select * from user where name = 'Jack' for update 的時候，就不止是給數據庫中已有的 n 個記錄加上了行鎖，還同時加了 n + 1 個間隙鎖(這兩個合起來也成為 Next-Key Lock 臨鍵鎖)。也就是說，在數據庫一行行掃描的過程中，不僅掃描到的行加上了行鎖，還給行兩邊的空隙也加上了鎖。這樣就確保了無法再插入新的記錄。

這里多提一嘴，update、delete 語句用不上索引是很恐怖的。

對非索引字段進行 select .. for update、update 或者 delete 操作，由于沒有索引，走全表查詢，就會對所有行記錄 以及 所有間隔 都進行上鎖。而對于索引字段進行上述操作，只有索引字段本身和附近的間隔會被加鎖。

總結下 MySQL 解決幻讀的手段：

隔離級別：可重復讀

• 快照讀 MVCC + 當前讀 Next-Lock Key(只在可重復讀隔離級別下生效)

隔離級別：SERIALIZABLE

• 在這個隔離級別下，事務在讀操作時，先加表級別的共享鎖，直到事務結束才釋放;事務在寫操作時，先加表級別的排它鎖，直到事務結束才釋放。也就是說，串行化鎖定了整張表，幻讀不存在的

最后放上這道題的背誦版：

面試官：幻讀有什么問題，MySQL 是如何解決幻讀的

小牛肉：幻讀就是一個事務在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。

幻讀的后果就是數據庫中的數據和 binlog 的執行結果會不一致，其原因就在于，我們無法阻止新插入的數據。就是說，我們在給掃描到的行加鎖的時候，你等會要插入的行還不存在，也就沒法對他進行加鎖，那么這個新插入的數據，可能在主庫中是這個樣子，從庫執行完 binlog 后其實是會被修改的。

這也就是為啥幻讀會被單獨拎出來解決的原因了。

幻讀問題在 "當前讀" 下才會出現。

所謂當前讀就是，讀取的是最新版本的數據, 并且對讀取的記錄加鎖, 阻塞其他事務同時改動相同記錄，避免出現安全問題。

與之對應的，快照讀，讀取的是快照中的數據，不需要進行加鎖。讀取已提交和可重復讀這倆隔離級別下的普通 select 操作就是快照讀。其實就是 MVCC 機制，或者說，在快照讀下，采用 MVCC 機制解決幻讀。

然后，對于當前讀這種情況，前面我們說，由于無法阻止新插入的數據，所以無法解決幻讀問題，所以，我們考慮，不僅對掃描到的行進行加鎖，還對行之間的間隙進行加鎖，這樣就能杜絕新數據的插入和更新。這個其實就是記錄鎖 Record Lock 和間隙鎖 Gap Lock，也被稱為臨鍵鎖 Next-Lock Key。

 額臨鍵鎖只在可重復讀也就是 InnoDB 的默認隔離級別下生效。也可以采用更高的可串行化隔離級別，所有的操作都是串行執行的，可以直接杜絕幻讀問題。