InnoDB的RR到底有沒有解決幻讀？

作者：派大星 2024-04-25 08:16:06

數據庫 MariaDB

在Repeatable Read隔離級別下，通過MVCC機制解決了快照讀導致的幻讀問題。在該隔離級別下，進行快照讀時僅在第一次進行數據查詢，隨后直接讀取快照，因此不會發生幻讀。

在InnoDB中，Repeatable Read（重復讀）隔離級別通過間隙鎖和MVCC機制解決了大部分的幻讀問題，但并非所有幻讀都能被解決。要徹底解決幻讀，需要使用Serializable（可串行化）隔離級別。

在Repeatable Read隔離級別下，通過間隙鎖解決了部分當前讀導致的幻讀問題。通過添加間隙鎖來鎖定記錄之間的間隙，以防止新數據的插入。

然而，若兩個事務操作如下：事務1首先進行快照讀，然后事務2插入一條記錄并提交，在事務1之后通過更新操作這個新插入的記錄，這樣可以成功更新，這就是幻讀的一種情況。

另外一個場景是，若兩個事務的順序為：事務1先進行快照讀，接著事務2插入了一條記錄并提交，在事務1進行當前讀后，再次進行快照讀也會導致幻讀的發生。

MVCC解決幻讀

MVCC，即多版本并發控制（Multiversion Concurrency Control），類似于數據庫鎖，是一種并發控制的解決方案。它主要用于解決讀-寫并發的情況。

我們了解，在MVCC中存在兩種讀取方式：快照讀和當前讀。

快照讀指的是讀取快照數據，即在生成快照的那一瞬間的數據。例如，通常情況下我們使用的普通SELECT語句在不加鎖的情況下就是一種快照讀。

在可重復讀（RC）中，每次讀取都會重新生成一個快照，始終讀取行的最新版本。在可重復讀（RR）中，快照會在事務第一次執行SELECT語句時生成，只有在本事務中對數據進行更改才會更新快照。

因此，在RR隔離級別下，同一事務中的多次查詢不會檢索到其他事務的更改內容，因此能夠解決幻讀問題。

若我們將事務隔離級別設置為RR，由于MVCC的機制，就可以解決幻讀問題。

有這樣一張表：

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,'Paidaxing');
INSERT INTO users(gmt_create,age,name) values(now(),28,'Paidaxing2023');
INSERT INTO users(gmt_create,age,name) values(now(),38,'Paidaxing666');

執行如下事務時序：

事務1
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM users WHERE AGE > 10 AND AGE <30;
	BEGIN;
	INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999');
	COMMIT;
SELECT * FROM users WHERE AGE > 10 AND AGE < 30;

可以觀察到，在同一個事務中，兩次查詢的結果是相同的。在可重復讀（RR）級別下，由于采用了快照讀，第二次查詢實際上是讀取的快照數據。

間隙鎖與幻讀

我們已經討論了MVCC如何解決了可重復讀（RR）級別下的快照讀造成的幻讀問題，那么在當前讀取（READ COMMITTED）下，如何解決幻讀問題呢？

當前讀取即讀取最新數據，因此，鎖定的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 ...

舉一個下面的例子：

事務1	事務2
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM users WHERE AGE > 10 AND AGE < 30 for update;
	BEGIN;
	INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999');
	阻塞

在可重復讀（RR）級別下，當我們使用SELECT … FOR UPDATE時，會進行鎖定操作。這不僅會對行記錄進行加鎖，還會對記錄之間的間隙進行加鎖，這就是所謂的間隙鎖。

由于記錄之間的間隙被鎖定，事務2的插入操作被阻塞，直到事務1釋放鎖才得以成功執行。

由于事務2無法成功插入數據，因此幻讀現象得以避免。因此，在可重復讀（RR）級別中，通過引入間隙鎖的方式，成功規避了幻讀現象的發生。

解決不了的幻讀

前面我們討論了快照讀（無鎖查詢）和當前讀（有鎖查詢）是如何解決幻讀問題的。然而，上面提到的例子并非幻讀的全部情況。

我們知道MVCC只能解決快照讀導致的幻讀問題，那么如果一個事務中發生了當前讀，在另一個事務插入數據前未加間隙鎖，會發生什么呢？

接下來，我們稍作修改上面的SQL代碼，采用當前讀方式來查詢數據：

事務1	事務2
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM users WHERE AGE > 10 AND AGE <30;
	BEGIN;
	INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999');
	COMMIT;
SELECT * FROM users WHERE AGE > 10 AND AGE < 30;
SELECT * FROM users WHERE AGE > 10 AND AGE < 30 for update;

在上面的例子中，在事務1中，我們并未在事務剛啟動時立即加鎖，而是進行了一次普通的查詢，隨后事務2成功插入數據后，事務1再進行了兩次查詢。

我們觀察到，事務1后兩次查詢的結果完全不同。在沒有加鎖的情況下，即快照讀時，讀取的數據與第一次查詢結果相同，從而避免了幻讀現象。但第二次查詢執行了鎖定操作，即當前讀，因此讀取到的數據中包含了其他事務提交的數據，導致了幻讀的發生。

倘若您理解了上述例子以及當前讀的概念，您將很容易意識到，下面的這個案例事實上也會導致幻讀的發生：

事務1	事務2
SET session TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT * FROM users WHERE AGE > 10 AND AGE <30;
	BEGIN;
	INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999');
	COMMIT;
SELECT * FROM users WHERE AGE > 10 AND AGE <30;
UPDATE users set name = "Paidaxing888" where age = 20;
SELECT * FROM users WHERE AGE > 10 AND AGE <30;