Innodb 的 RR 到底有没有解决幻读？

在 InnoDB 中，Repeatable Read（重复读）隔离级别通过间隙锁和 MVCC 机制解决了大部分的幻读问题，但并非所有幻读都能被解决。要彻底解决幻读，需要使用 Serializable（可串行化）隔离级别。

在 Repeatable Read 隔离级别下，通过间隙锁解决了部分当前读导致的幻读问题。通过添加间隙锁来锁定记录之间的间隙，以防止新数据的插入。

在 Repeatable Read 隔离级别下，通过 MVCC 机制解决了快照读导致的幻读问题。在该隔离级别下，进行快照读时仅在第一次进行数据查询，随后直接读取快照，因此不会发生幻读。

然而，若两个事务操作如下：事务 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');

执行如下事务时序：

可以观察到，在同一个事务中，两次查询的结果是相同的。在可重复读（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 ...

举一个下面的例子：

在可重复读（RR）级别下，当我们使用 SELECT … FOR UPDATE 时，会进行锁定操作。这不仅会对行记录进行加锁，还会对记录之间的间隙进行加锁，这就是所谓的间隙锁。

由于记录之间的间隙被锁定，事务 2 的插入操作被阻塞，直到事务 1 释放锁才得以成功执行。

由于事务 2 无法成功插入数据，因此幻读现象得以避免。因此，在可重复读（RR）级别中，通过引入间隙锁的方式，成功规避了幻读现象的发生。

解决不了的幻读

前面我们讨论了快照读（无锁查询）和当前读（有锁查询）是如何解决幻读问题的。然而，上面提到的例子并非幻读的全部情况。

我们知道 MVCC 只能解决快照读导致的幻读问题，那么如果一个事务中发生了当前读，在另一个事务插入数据前未加间隙锁，会发生什么呢？

接下来，我们稍作修改上面的 SQL 代码，采用当前读方式来查询数据：

在上面的例子中，在事务 1 中，我们并未在事务刚启动时立即加锁，而是进行了一次普通的查询，随后事务 2 成功插入数据后，事务 1 再进行了两次查询。

我们观察到，事务 1 后两次查询的结果完全不同。在没有加锁的情况下，即快照读时，读取的数据与第一次查询结果相同，从而避免了幻读现象。但第二次查询执行了锁定操作，即当前读，因此读取到的数据中包含了其他事务提交的数据，导致了幻读的发生。

倘若您理解了上述例子以及当前读的概念，您将很容易意识到，下面的这个案例事实上也会导致幻读的发生：

这里产生幻读的原因和前面的例子实际上是相同的。即，MVCC 只能解决快照读中的幻读问题，而对于当前读（例如 SELECT FOR UPDATE、UPDATE、DELETE 等操作）仍会导致幻读的产生。在同一个事务中同时进行快照读和当前读操作时，将导致幻读的发生。

UPDATE 语句也属于当前读操作，因此它有可能读取到其他事务提交的结果。

为何事务 1 最后一次查询和倒数第二次查询的结果会不同呢？

原因在于根据快照读的定义，在可重复读级别下，如果在本事务中发生了数据修改，将会更新快照数据，因此最后一次查询的结果也会相应地发生变化。

如何避免幻读

了解了幻读产生的情境以及无法解决的几种情况后，让我们总结一下如何解决幻读的问题。

首先，若欲彻底解决幻读问题，在 InnoDB 中唯一可选的隔离级别是 Serializable（可串行化）级别。

图源：MySQL 8.0 参考手册

若希望在一定程度上解决或避免幻读，可考虑使用可重复读（RR）隔离级别，但读提交（RC）和读未提交（RU）级别肯定不可行。

在可重复读级别中，尽量使用快照读（无锁查询），这样不仅可以减少锁冲突、提高并发度，还能避免幻读问题的发生。

在高并发场景中若必须加锁，应在事务开始时立即加锁，这将引入间隙锁，有效地避免幻读。

然而，值得注意的是，间隙锁是引发死锁的重要因素，因此在使用时需要谨慎对待。

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或微信搜索【码上遇见你】。

免费的Chat GPT可微信搜索【AI贝塔】进行体验，无限使用。

好了，本章节到此告一段落。希望对你有所帮助，祝学习顺利。