Innodb的RR到底有沒有解決幻讀？看不懂你打我！

作者：Hollis 2022-12-27 10:02:38

在RR級(jí)別中，因?yàn)橛蠱VCC機(jī)制，對(duì)于普通的無(wú)鎖查詢，這種是屬于快照讀的，RR的快照讀在同一個(gè)事務(wù)中只會(huì)讀一次，所以在事務(wù)過程中，其他事務(wù)的變更不會(huì)影響到當(dāng)前事務(wù)的查詢結(jié)果。所以這種幻讀是可以解決的。

關(guān)于Innodb中的REPEATABLE READ這種隔離級(jí)別到底有沒有解決幻讀？好像眾說紛紜，大家的說法都不一致。

有的人說，RR當(dāng)然沒解決幻讀了，因?yàn)橹挥蠸erializable才能解決幻讀。

也有人說，RR解決了幻讀，因?yàn)镽R中加了間隙鎖，就能解決幻讀的問題。

還有人說，只有間隙鎖是沒用的，還有MVCC也幫助RR解決了幻讀的問題。

那到底真實(shí)情況是怎么樣的呢？

?我認(rèn)為，InnoDB中的REPEATABLE READ這種隔離級(jí)別通過間隙鎖+MVCC解決了大部分的幻讀問題，只有一種特殊的幻讀情況無(wú)法解決。

為什么這么說呢？這種特殊情況是怎么回事兒呢？本文就來把這個(gè)問題講清楚。(本文中所有SQL的運(yùn)行環(huán)境是MySQL 5.7.9 及MySQL 8.0.30）?

什么是幻讀

?在介紹如何解決幻讀之前，有必要再明確一下什么是幻讀，確保大家理解是一致的。

幻讀就是事務(wù)在做范圍查詢（SELECT)的過程中，有另外一個(gè)事務(wù)對(duì)范圍內(nèi)新增了記錄(INSERT)，導(dǎo)致范圍查詢的結(jié)果條數(shù)不一致的現(xiàn)象。?

有這樣一張表：?

CREATE TABLE users (    id INT UNSIGNED AUTO_INCREMENT,    gmt_create DATETIME NOT NULL,    age INT NOT NULL,    name VARCHAR(16) NOT NULL,    PRIMARY KEY (id)
) ENGINE=InnoDB;
INSERT INTO users(gmt_create,age,name) values(now(),18,'Hollis');INSERT INTO users(gmt_create,age,name) values(now(),28,'HollisChuang');INSERT INTO users(gmt_create,age,name) values(now(),38,'Hollis666');

接著我們進(jìn)行如下操作：

在這個(gè)例子中，在事務(wù)1中執(zhí)行了兩次相同的查詢操作。但是兩次操作中間事務(wù)2向數(shù)據(jù)庫(kù)中增加了一條符合事務(wù)1的查詢條件的數(shù)據(jù)，最終事務(wù)1的兩次查詢得到的結(jié)果是不一樣的，這種現(xiàn)象就是幻讀。

MVCC與幻讀?

MVCC，是Multiversion Concurrency Control的縮寫，翻譯過來是多版本并發(fā)控制，和數(shù)據(jù)庫(kù)鎖一樣，他也是一種并發(fā)控制的解決方案。它主要用來解決讀-寫并發(fā)的情況。關(guān)于MVCC的原理可以參考《??再有人問你什么是MVCC，就把這篇文章發(fā)給他！???》

我們知道，在MVCC中有兩種讀，一種是快照讀、一種是當(dāng)前讀。

所謂快照讀，就是讀取的是快照數(shù)據(jù)，即快照生成的那一刻的數(shù)據(jù)，像我們常用的普通的SELECT語(yǔ)句在不加鎖情況下就是快照讀。

SELECT * FROM xx_table WHERE ...

在 RC 中，每次讀取都會(huì)重新生成一個(gè)快照，總是讀取行的最新版本。

在 RR 中，快照會(huì)在事務(wù)中第一次SELECT語(yǔ)句執(zhí)行時(shí)生成，只有在本事務(wù)中對(duì)數(shù)據(jù)進(jìn)行更改才會(huì)更新快照。

那么也就是說，如果在RR下，一個(gè)事務(wù)中的多次查詢，是不會(huì)查詢到其他的事務(wù)中的變更內(nèi)容的，所以，也就是可以解決幻讀的。

所以，針對(duì)上面的例子，如果我們把事務(wù)隔離級(jí)別設(shè)置為RR，那么因?yàn)橛辛薓VCC的機(jī)制，就能解決幻讀的問題：?

可以看到，同一個(gè)事務(wù)中的兩次查詢結(jié)果是一樣的，就是在RR級(jí)別下，因?yàn)橛锌煺兆x，所以第二次查詢其實(shí)讀取的是一個(gè)快照數(shù)據(jù)。

間隙鎖與幻讀

?上面我們講過了MVCC能解決RR級(jí)別下面的快照讀的幻讀問題，那么當(dāng)前讀下面的幻讀問題怎么解決呢？

當(dāng)前讀就是讀取最新數(shù)據(jù)，所以，加鎖的 SELECT，或者對(duì)數(shù)據(jù)進(jìn)行增刪改都會(huì)進(jìn)行當(dāng)前讀，比如：?

SELECT * FROM xx_table LOCK IN SHARE MODE;
SELECT * FROM xx_table FOR UPDATE;
INSERT INTO xx_table ...
DELETE FROM xx_table ...
UPDATE xx_table ...

舉一個(gè)下面的例子：

像上面這種情況，在RR的級(jí)別下，當(dāng)我們使用SELECT … FOR UPDATE的時(shí)候，會(huì)進(jìn)行加鎖，不僅僅會(huì)對(duì)行記錄進(jìn)行加鎖，還會(huì)對(duì)記錄之間的間隙進(jìn)行加鎖，這就叫做間隙鎖（參考：??數(shù)據(jù)庫(kù)的鎖，到底鎖的是什么？???）。因?yàn)橛涗浿g的間隙被鎖住了，所以事務(wù)2的插入操作就被阻塞了，一直到事務(wù)1把鎖釋放掉他才能執(zhí)行成功。

因?yàn)槭聞?wù)2無(wú)法插入數(shù)據(jù)成功，所以也就不會(huì)存在幻讀的現(xiàn)象了。所以，在RR級(jí)別中，通過加入間隙鎖的方式，就避免了幻讀現(xiàn)象的發(fā)生。

解決不了的幻讀

前面我們介紹了快照讀（無(wú)鎖查詢）和當(dāng)前讀（有鎖查詢）下是如何解決幻讀的問題的，但是，上面的例子就是幻讀的所有情況了嗎？顯然并不是。

我們說MVCC只能解決快照讀的幻讀，那如果在一個(gè)事務(wù)中發(fā)生了當(dāng)前讀，并且在另一個(gè)事務(wù)插入數(shù)據(jù)前沒來得及加間隙鎖的話，會(huì)發(fā)生什么呢？

那么，我們稍加修改一下上面的SQL代碼，通過當(dāng)前讀的方式進(jìn)行查詢數(shù)據(jù)：

在上面的例子中，在事務(wù)1中，我們并沒有在事務(wù)開啟后立即加鎖，而是進(jìn)行了一次普通的查詢，然后事務(wù)2插入數(shù)據(jù)成功之后，再通過事務(wù)1進(jìn)行了2次查詢。

?我們發(fā)現(xiàn)，事務(wù)1后面的兩次查詢結(jié)果完全不一樣，沒加鎖的情況下，就是快照讀，讀到的數(shù)據(jù)就和第一次查詢是一樣的，就不會(huì)發(fā)生幻讀。但是第二次查詢加了鎖，就是當(dāng)前讀，那么讀取到的數(shù)據(jù)就有其他事務(wù)提交的數(shù)據(jù)了，就發(fā)生了幻讀。

那么，如果你理解了上面的這個(gè)例子，并且你也理解了當(dāng)前讀的概念，那么你很容易就能想到，下面的這個(gè)CASE其實(shí)也是會(huì)發(fā)生幻讀的：