[[437528]]

本文轉(zhuǎn)載自微信公眾號「飛天小牛肉」，作者飛天小牛肉 。轉(zhuǎn)載本文請聯(lián)系飛天小牛肉公眾號。

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

當前讀和快照讀

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

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

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

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

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

開啟兩個事務：

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

沒毛病，很正常。

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

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

是的，仍然是舊數(shù)據(jù)：

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

幻讀到底有什么問題

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

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

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

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

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

不多廢話，直接上例子：

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

有如下三個事務：

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

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

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

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

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

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

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

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

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

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

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

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

其次，最重要的是，是數(shù)據(jù)一致性的問題。

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

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

我在上圖中圈出了四個時刻， T1 T2 T3 和 T4，我們來分析下經(jīng)過這四個時刻的數(shù)據(jù)庫狀態(tài)：

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

再來看看這時候 binlog 日志里面的內(nèi)容，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 一執(zhí)行，那豈不是原先 (2, Jack, 40) 和 (3, Jack, 30) 這兩行的 name 全都變成了 Tom。

也就是說，id = 2 和 id = 3 這兩行，發(fā)生了數(shù)據(jù)不一致。

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

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

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

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

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

來看 binlog，執(zhí)行序列是這樣的：

事務 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，在數(shù)據(jù)庫里面的結(jié)果是 (3, "Jack", 30)，而根據(jù) binlog 的執(zhí)行結(jié)果是 (3, Tom, 30)，也就是說幻讀的問題還是沒有解決。

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

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

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

MySQL 如何解決幻讀

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

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

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

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

總結(jié)下 MySQL 解決幻讀的手段：

隔離級別：可重復讀

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

隔離級別：SERIALIZABLE

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

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

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

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

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

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

幻讀問題在 "當前讀" 下才會出現(xiàn)。

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

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

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

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