源 /艾小仙文/ 艾小仙

前面我寫了很多Mysql相關(guān)的知識點，到這一篇稍微可以串一下了，從SQL執(zhí)行流程、MVCC到鎖，很多時候可能覺得對于間隙鎖和Next-Key Lock好像已經(jīng)理解了，但是好像又覺得理解差那么一點意思，這篇文章從頭來梳理一下概念，明確一下這些知識。

鎖

首先，對于Mysql來說實現(xiàn)了兩種行級鎖：

共享鎖：允許事務(wù)讀一行數(shù)據(jù)，一般記為S，也稱為讀鎖

排他鎖：允許事務(wù)刪除或者更新一行數(shù)據(jù)，一般記為X，也稱為寫鎖

關(guān)于讀寫鎖的互斥性，應(yīng)該都很清楚，讀鎖只能和讀鎖兼容，其他場景都無法兼容，這里不再贅述吧。

隔離級別

繼續(xù)回顧下關(guān)于Mysql的4個隔離級別：

讀未提交Read Uncommitted：能讀到其他事務(wù)還沒有提交的數(shù)據(jù)，這種現(xiàn)象叫做臟讀。

讀已提交Read Committed：只會讀取其他事務(wù)已經(jīng)提交的數(shù)據(jù)，所以不會產(chǎn)生RC的臟讀問題。所以又帶來一個問題叫做不可重復(fù)讀，一個事務(wù)中兩次一樣的SQL查詢可能查到的結(jié)果不一樣。

可重復(fù)讀Repeatable Read：RR是Mysql的默認(rèn)隔離級別，一個事務(wù)中兩次SQL查詢總是會查到一樣的結(jié)果，不存在不可重復(fù)讀的問題，但是還是會有幻讀的問題。

串行Serializable：串行場景沒有任何問題，完全串行化的操作，讀加讀鎖，寫加寫鎖。

幻讀、Next-Key Lock、MVCC

簡單的回顧完了基礎(chǔ)，那么我們看看RR級別下還會存在的幻讀到底是什么問題，Mysql官方文檔這樣描述的：

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.

翻譯過來就是，幻讀指的是同一事務(wù)下，不同的時間點，同樣的查詢，得到不同的行記錄的集合。

如果說一個select執(zhí)行了兩次，但是第二次比第一次多出來行記錄，這就是幻讀。

所以，對于幻讀來說那一定是新增插入的數(shù)據(jù)！

比如說在一個事務(wù)內(nèi)，先查詢select * from user where age=10 for update，得到的結(jié)果是id為[1,2,3]的記錄，再次執(zhí)行查詢，得到了結(jié)果為[1,2,3,4]的記錄，這是幻讀。

那怎么解決幻讀的問題？以前我在文章里說解決幻讀的原理是MVCC（MVCC原理看這里）很多網(wǎng)上的文章也有這么寫的，其實不能說錯，但是肯定也是不太對的，準(zhǔn)確地來說應(yīng)該是通過MVCC+Next-Key Lock的方式才解決了幻讀的問題。

對于MVCC中的讀可以分為兩種，分別叫做快照讀和當(dāng)前讀(這個當(dāng)前讀的說法我在書里翻了半天也沒有找到，但是看網(wǎng)上一堆資料和大佬都叫當(dāng)前讀，那么我們就叫當(dāng)前讀吧，你知道的話可以告訴我哪本書有這個稱呼，Mysql我只看見Lock reading或者鎖定讀的叫法，有的也說鎖定讀就是當(dāng)前讀，但是并沒有找到當(dāng)前讀這種稱呼的出處在哪兒)。

快照讀就是簡單的select查詢，查詢的都是快照版本，這個場景下因為都是基于MVCC來查詢快照的某個版本，所以不會存在幻讀的問題，也可以認(rèn)為是解決了幻讀的方案之一，對于RC級別來說，因為每次查詢都重新生成一個read view，也就是查詢的都是最新的快照數(shù)據(jù)，所以會可能每次查詢到不一樣的數(shù)據(jù)，造成不可重復(fù)讀，而對于RR級別來說只有第一次的時候生成read view，查詢的是事務(wù)開始的時候的快照數(shù)據(jù)，所以就不存在不可重復(fù)讀的問題，當(dāng)然就更不可能有幻讀的問題了。

所以，現(xiàn)在我們說幻讀，其實不是指快照讀的場景，而是指的是當(dāng)前讀的場景。

當(dāng)前讀指的是lock in share mode、for update 、insert、update、delete這些需要加鎖的操作。對于MVCC來說就是解決的快照讀的場景，而對于當(dāng)前讀那么就是Next-Key Lock要解決的事情。

那么Next-Key Lock是什么？怎么解決的幻讀？

行鎖有寫鎖X和讀鎖S兩種，實際上行鎖有3種實現(xiàn)算法，Next-Key Lock是其中之一。

第一種叫做Record Lock，字面意思，行記錄的鎖，實際上指的是對索引記錄的鎖定。

比如執(zhí)行語句select * from user where age=10 for update，將會鎖住user表所有age=10的行記錄，所有對age=10的記錄的操作都會被阻塞。

第二種都比較熟悉，叫做Gap Lock，也就是間隙鎖，它用于鎖定的索引之間的間隙，但是不會包含記錄本身。

比如語句select * from user where age>1 and age<10 for update，將會鎖住age在(1,10)的范圍區(qū)間，此時其他事務(wù)對該區(qū)間的操作都會被阻塞。

間隙鎖是可重復(fù)讀RR隔離級別下特有的，另外還有幾種場景也會不使用間隙鎖。

事務(wù)隔離級別設(shè)置為讀已提交RC ，這樣肯定沒有間隙鎖了。
Innodb_locks_unsafe_for_binlog設(shè)置為1
另外一種情況適用于主鍵索引或者唯一索引的等值查詢條件，比如select * from user where id=1，id是主鍵索引，這樣只使用Record Lock就可以了，因為能唯一鎖定一條記錄，所以沒有必要再加間隙鎖了，這是鎖降級的過程。

而第三種Next-Key Lock實際上就是相當(dāng)于Record Lock+Gap Lock的組合。比如索引有10，20，30幾個值，那么被鎖住的區(qū)間可能會是(-∞,10]，(10,20]，(20,30]，(30,+∞)。

解決幻讀

上一篇關(guān)于更新SQL執(zhí)行過程我們已經(jīng)對這個基礎(chǔ)有了一定的了解，在這里我們?nèi)サ艉瓦@里內(nèi)容無關(guān)的一些日志的細(xì)節(jié)，把給數(shù)據(jù)加鎖的流程加入進(jìn)去，這樣通過SQL執(zhí)行可以更好地理解Next-Key Lock到底是如何解決幻讀的，執(zhí)行過程如下：

首先第一步Server層會來查詢數(shù)據(jù)
存儲引擎根據(jù)查詢條件查到數(shù)據(jù)之后對數(shù)據(jù)進(jìn)行加鎖，Record Lock或者間隙鎖，然后返回數(shù)據(jù)
Server層拿到數(shù)據(jù)之后調(diào)用API去存儲引擎更新數(shù)據(jù)
最后存儲引擎返回結(jié)果，流程結(jié)束