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

作者 l Hollis

來源 l Hollis（ID：hollischuang）

關於 Innodb 中的 REPEATABLE READ 這種隔離級別到底有沒有解決幻讀？好像衆說紛紜，大家的說法都不一致。

有的人說，RR 當然沒解決幻讀了，因爲只有 Serializable 才能解決幻讀。

也有人說，RR 解決了幻讀，因爲 RR 中加了間隙鎖，就能解決幻讀的問題。

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

那到底真實情況是怎麼樣的呢？

我認爲，InnoDB 中的 REPEATABLE READ 這種隔離級別通過間隙鎖 + MVCC 解決了大部分的幻讀問題，只有一種特殊的幻讀情況無法解決。

爲什麼這麼說呢？這種特殊情況是怎麼回事兒呢？本文就來把這個問題講清楚。(本文中所有 SQL 的運行環境是 MySQL 5.7.9 及 MySQL 8.0.30）

什麼是幻讀

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

幻讀就是事務在做範圍查詢（SELECT) 的過程中，有另外一個事務對範圍內新增了記錄 (INSERT)，導致範圍查詢的結果條數不一致的現象。

有這樣一張表：

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');

接着我們進行如下操作：

在這個例子中，在事務 1 中執行了兩次相同的查詢操作。但是兩次操作中間事務 2 向數據庫中增加了一條符合事務 1 的查詢條件的數據，最終事務 1 的兩次查詢得到的結果是不一樣的，這種現象就是幻讀。

MVCC 與幻讀

MVCC，是 Multiversion Concurrency Control 的縮寫，翻譯過來是多版本併發控制，和數據庫鎖一樣，他也是一種併發控制的解決方案。它主要用來解決讀 - 寫併發的情況。關於 MVCC 的原理可以參考《再有人問你什麼是 MVCC，就把這篇文章發給他！》

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

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

SELECT * FROM xx_table WHERE ...

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

在 RR 中，快照會在事務中第一次 SELECT 語句執行時生成，只有在本事務中對數據進行更改纔會更新快照。

那麼也就是說，如果在 RR 下，一個事務中的多次查詢，是不會查詢到其他的事務中的變更內容的，所以，也就是可以解決幻讀的。

所以，針對上面的例子，如果我們把事務隔離級別設置爲 RR，那麼因爲有了 MVCC 的機制，就能解決幻讀的問題：

可以看到，同一個事務中的兩次查詢結果是一樣的，就是在 RR 級別下，因爲有快照讀，所以第二次查詢其實讀取的是一個快照數據。

間隙鎖與幻讀

上面我們講過了 MVCC 能解決 RR 級別下面的快照讀的幻讀問題，那麼當前讀下面的幻讀問題怎麼解決呢？

當前讀就是讀取最新數據，所以，加鎖的 SELECT，或者對數據進行增刪改都會進行當前讀，比如：

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 ...

舉一個下面的例子：

像上面這種情況，在 RR 的級別下，當我們使用 SELECT … FOR UPDATE 的時候，會進行加鎖，不僅僅會對行記錄進行加鎖，還會對記錄之間的間隙進行加鎖，這就叫做間隙鎖（參考：數據庫的鎖，到底鎖的是什麼？）。因爲記錄之間的間隙被鎖住了，所以事務 2 的插入操作就被阻塞了，一直到事務 1 把鎖釋放掉他才能執行成功。

因爲事務 2 無法插入數據成功，所以也就不會存在幻讀的現象了。所以，在 RR 級別中，通過加入間隙鎖的方式，就避免了幻讀現象的發生。

解決不了的幻讀

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

我們說 MVCC 只能解決快照讀的幻讀，那如果在一個事務中發生了當前讀，並且在另一個事務插入數據前沒來得及加間隙鎖的話，會發生什麼呢？

那麼，我們稍加修改一下上面的 SQL 代碼，通過當前讀的方式進行查詢數據：

在上面的例子中，在事務 1 中，我們並沒有在事務開啓後立即加鎖，而是進行了一次普通的查詢，然後事務 2 插入數據成功之後，再通過事務 1 進行了 2 次查詢。

我們發現，事務 1 後面的兩次查詢結果完全不一樣，沒加鎖的情況下，就是快照讀，讀到的數據就和第一次查詢是一樣的，就不會發生幻讀。但是第二次查詢加了鎖，就是當前讀，那麼讀取到的數據就有其他事務提交的數據了，就發生了幻讀。

那麼，如果你理解了上面的這個例子，並且你也理解了當前讀的概念，那麼你很容易就能想到，下面的這個 CASE 其實也是會發生幻讀的：

這裏發生幻讀的原理，和上面的例子其實是一樣的，那就是 MVCC 只能解決快照讀中的幻讀問題，而對於當前讀（SELECT FOR UPDATE、UPDATE、DELETE 等操作）還是會產生幻讀的現象的。

UPDATE 語句也是一種當前讀，所以它是可以讀到其他事務的提交結果的。

爲什麼事務 1 的最後一次查詢和倒數第二次查詢的結果也不一樣呢？

是因爲根據快照讀的定義，在 RR 中，如果本事務中發生了數據的修改，那麼就會更新快照，那麼最後一次查詢的結果也就發生了變化。

如何避免幻讀

那麼瞭解了幻讀的解決場景，以及不能解決的幾個 CASE 之後，我們來總結一下該如何解決幻讀的問題呢？

首先，如果想要徹底解決幻讀的問題，在 InnoDB 中只能使用 Serializable 這種隔離級別。

圖源：MySQL 8.0 Reference Manual

那麼，如果想在一定程度上解決或者避免發生幻讀的話，使用 RR 也可以，但是 RC、RU 肯定是不行的。

在 RR 級別中，能使用快照讀（無鎖查詢）的就使用快照讀，這樣不僅可以減少鎖衝突，提升併發度，而且還能避免幻讀的發生。

那麼，如果在併發場景中，一定要加鎖的話怎麼辦呢？那就一定要在事務一開始就立即加鎖，這樣就會有間隙鎖，也能有效的避免幻讀的發生。

但是需要注意的是，間隙鎖是導致死鎖的一個重要根源~ 所以，用起來也需要慎重。

總結

在 RC 級別中，幻讀是沒有辦法解決的，因爲 RC 中快照讀是每一次都會重新生成快照，並且 RC 中也不會有間隙鎖。

在 RR 級別中，因爲有 MVCC 機制，對於普通的無鎖查詢，這種是屬於快照讀的，RR 的快照讀在同一個事務中只會讀一次，所以在事務過程中，其他事務的變更不會影響到當前事務的查詢結果。所以這種幻讀是可以解決的。

當時，MVCC 只能對快照讀起作用，而對於加鎖的讀請求，這種屬於當前讀，當前讀的話是可以查詢到其他事務的變更的，所以會產生幻讀。

想要解決幻讀，可以使用 Serializable 這種隔離級別，或者使用 RR 也能解決大部分的幻讀問題。

在 RR 級別下，爲了避免幻讀的發生，要麼就是使用快照讀，要麼就是在事務一開始就加鎖。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Pm6PQEYwStww6htOQAlDIg

猜你喜歡