?

?大家好，我是小林。

我之前寫過一篇數(shù)據(jù)庫事務的文章「?事務、事務隔離級別和MVCC」，這篇我說過什么是幻讀。幻讀的定義我這里還得補充一句，幻讀僅專指“新插入的行”，中途通過 update 更新數(shù)據(jù)而出現(xiàn)同一個事務前后兩次查詢的「結果集合」不一樣，這種不算幻讀。然后前幾天有位讀者跟我說，這個幻讀例子不是已經(jīng)被「可重復讀」隔離級別解決了嗎？為什么還要有 next-key 呢？他有這個質疑，是因為他做了這個實驗。實驗的數(shù)據(jù)庫表 t_stu 如下，其中 id 為主鍵。
然后在可重復讀隔離級別下，有兩個事務的執(zhí)行順序如下：
從這個實驗結果可以看到，即使事務 B 中途插入了一條記錄，事務 A 前后兩次查詢的結果集都是一樣的，并沒有出現(xiàn)所謂的幻讀現(xiàn)象。讀者做的實驗之所以看不到幻讀現(xiàn)象，是因為在可重復讀隔離級別下，普通的查詢是快照讀，是不會看到別的事務插入的數(shù)據(jù)的。可重復讀隔離級是由 MVCC（多版本并發(fā)控制）實現(xiàn)的，實現(xiàn)的方式是啟動事務后，在執(zhí)行第一個查詢語句后，會創(chuàng)建一個視圖，然后后續(xù)的查詢語句都用這個視圖，「快照讀」讀的就是這個視圖的數(shù)據(jù)，視圖你可以理解為版本數(shù)據(jù)，這樣就使得每次查詢的數(shù)據(jù)都是一樣的。MySQL 里除了普通查詢是快照度，其他都是當前讀，比如update、insert、delete，這些語句執(zhí)行前都會查詢最新版本的數(shù)據(jù)，然后再做進一步的操作。這很好理解，假設你要 update 一個記錄，另一個事務已經(jīng) delete 這條記錄并且 提交事務了，這樣不是會產(chǎn)生沖突嗎，所以 update 的時候肯定要知道最新的數(shù)據(jù)。另外，select ... for update?這種查詢語句是當前讀，每次執(zhí)行的時候都是讀取最新的數(shù)據(jù)。?因此，要討論「可重復讀」隔離級別的幻讀現(xiàn)象，是要建立在「當前讀」的情況下。接下來，我們假設select ... for update當前讀是不會加鎖的（實際上是會加鎖的），在做一遍讀者那個實驗。這時候，事務 B 插入的記錄，就會被事務 A 的第二條查詢語句查詢到（因為是當前讀），這樣就會出現(xiàn)前后兩次查詢的結果集合不一樣，這就出現(xiàn)了幻讀。所以，Innodb 引擎為了解決「可重復讀」隔離級別使用「當前讀」而造成的幻讀問題，就引出了 next-key 鎖，就是記錄鎖和間隙鎖的組合。

• 記錄鎖，鎖的是記錄本身；

• 間隙鎖，鎖的就是兩個值之間的空隙，以防止其他事務在這個空隙間插入新的數(shù)據(jù)，從而避免幻讀現(xiàn)象。

比如，下面事務 A 查詢語句會鎖住(2, ∞]范圍的記錄，然后期間如果有其他事務在這個鎖住的范圍插入數(shù)據(jù)就會被阻塞。next-key 鎖的加鎖規(guī)則其實挺復雜的，在一些場景下會退化成記錄鎖或間隙鎖，我之前也寫一篇加鎖規(guī)則，詳細可以看這篇「我做了一天的實驗！」需要注意的是，next-key lock 鎖的是索引，而不是數(shù)據(jù)本身，所以如果 update 語句的 where 條件沒有用到索引列，那么就會全表掃描，在一行行掃描的過程中，不僅給行加上了行鎖，還給行兩邊的空隙也加上了間隙鎖，相當于鎖住整個表，然后直到事務結束才會釋放鎖。所以在線上千萬不要執(zhí)行沒有帶索引條件的 update 語句，不然會造成業(yè)務停滯，我有個讀者就因為干了這個事情，然后被老板教育了一波，詳細可以看這篇「完蛋，公司被一條 update 語句干趴了！」好了，這次就聊到這啦，有不明白的地方歡迎討論！??