再探幻读！什么是幻读?为什么会产生幻读，MySQL中是怎么解决幻读的？

文章目录

什么是幻读
可重复读隔离下为什么会产生幻读？
- MySQL中如何实现可重复读
如何解决幻读

什么是幻读

先来看看事务的隔离级别

然后，谈幻读之前，我先说说我对幻读的理解：
所谓幻读，重点在于“幻”这个词，很梦幻，很玄乎，真假不定，就像蒙上了一层雾一样，你不能真真切切的看到对方，给人以幻的感觉，这便是“幻”。而所谓的幻读，也就是你通过SELECT查询出来的数据集并不是真实存在的数据集，你通过SELECT语句查询出某条记录是不存在的，但是它有可能在真实的表中是存在的。
我是这么理解幻读与不可重复读的：

幻读说的是存不存在的问题：原来不存在的,现在存在了,则是幻读
不可重复读说的是变没变化的问题：原来是A,现在却变为了B,则为不可重复读

幻读，目前我了解的有两种说法：

说法一：事务 A 根据条件查询得到了 N 条数据，但此时事务 B 删除或者增加了 M 条符合事务 A 查询条件的数据，这样当事务 A 再次进行查询的时候真实的数据集已经发生了变化，但是A却查询不出来这种变化，因此产生了幻读。

这一种说法强调幻读在于某一个范围内的数据行变多或者是变少了，侧重说明的是数据集不一样导致了产生了幻读。

说法二：幻读并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些：A事务select 某记录是否存在，结果为不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。产生这样的原因是因为有另一个事务往表中插入了数据。

我个人更赞成第一种说法。

说法二这种情况也属于幻读，说法二归根到底还是数据集发生了改变，查询得到的数据集与真实的数据集不匹配。

对于说法二：当进行INSERT的时候，也需要隐式的读取，比如插入数据时需要读取有没有主键冲突，然后再决定是否能执行插入。如果这时发现已经有这个记录了，就没法插入。所以，SELECT 显示不存在，但是INSERT的时候发现已存在，说明符合条件的数据行发生了变化，也就是幻读的情况，而不可重复读指的是同一条记录的内容被修改了。

举例来说明：说法二说的是如下的情况：
有两个事务A和B，A事务先开启，然后A开始查询数据集中有没有id = 30的数据，查询的结果显示数据中没有id = 30的数据。紧接着又有一个事务B开启了，B事务往表中插入了一条id = 30的数据，然后提交了事务。然后A再开始往表中插入id = 30的数据，由于B事务已经插入了id = 30的数据，自然是不能插入，紧接着A又查询了一次，结果发现表中没有id = 30的数据呀，A事务就很纳闷了，怎么会插入不了数据呢。当A事务提交以后，再次查询，发现表中的确存在id = 30的数据。但是A事务还没提交的时候，却查不出来？
其实，这便是可重复读的作用。
过程如下图所示：

上图中操作的t表的创建语句如下：

CREATE TABLE `t` (`id` int(11) NOT NULL,`c` int(11) DEFAULT NULL,`d` int(11) DEFAULT NULL,PRIMARY KEY (`id`),KEY `c` (`c`) -- 创建索引
) ENGINE=InnoDB;INSERT INTO t VALUES(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);

MySQL使用的InnoDB引擎默认的隔离级别是可重复读，也就是说在同一个事务中，两次执行同样的查询，得到的效果应该是一样的。因此，尽管B事务在A事务还未结束的时候，增加了表中的数据，但是为了维护可重复读，A事务中不管怎么查询，是查询不了新增的数据的。但是对于真实的表而言，表中的数据是的的确确增加了。

A查询不到这个数据，不代表这个数据不存在。查询得到了某条数据，不代表它真的存在。这样是是而非的查询，就像是幻觉一样，似真似假，故为幻读。
产生幻读的原因归根到底是由于查询得到的结果与真实的结果不匹配。

幻读 VS 不可重复读

幻读重点在于数据是否存在。原本不存在的数据却真实的存在了，这便是幻读。在同一个事务中，第一次读取到结果集和第二次读取到的结果集不同。（对比上面的例子，当B事务INSERT以后，A事务中再进行插入，此次插入相当于一次隐式查询）。引起幻读的原因在于另一个事务进行了INSERT操作。
不可重复读重点在于数据是否被改变了。在一个事务中对同一条记录进行查询，第一次读取到的数据和第二次读取到的数据不一致，这便是可重复读。引起不可重复读的原因在于另一个事务进行了UPDATE或者是DELETE操作。

简单来说：幻读是说数据的条数发生了变化，原本不存在的数据存在了。不可重复读是说数据的内容发生了变化，原本存在的数据的内容发生了改变。

可重复读隔离下为什么会产生幻读？

在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在 当前读 下才会出现。

什么是快照读，什么是当前读？

快照读读取的是快照数据。不加锁的简单的 SELECT都属于快照读，比如这样：

SELECT * FROM player WHERE ...

当前读就是读取最新数据，而不是历史版本的数据。加锁的 SELECT，或者对数据进行增删改都会进行当前读。这有点像是 Java 中的 volatile 关键字，被 volatile 修饰的变量，进行修改时，JVM 会强制将其写回内存，而不是放在 CPU 缓存中，进行读取时，JVM 会强制从内存读取，而不是放在 CPU 缓存中。这样就能保证其可见行，保证每次读取到的都是最新的值。如果没有用 volatile 关键字修饰，变量的值可能会被放在 CPU 缓存中，这就导致读取到的值可能是某次修改的值，不能保证是最新的值。

说多了，我们继续来看，如下的操作都会进行 当前读。

SELECT * FROM player LOCK IN SHARE MODE;
SELECT * FROM player FOR UPDATE;
INSERT INTO player values ...
DELETE FROM player WHERE ...
UPDATE player SET ...

说白了，快照读就是普通的读操作，而当前读包括了 加锁的读取 和 DML（DML只是对表内部的数据操作，不涉及表的定义，结构的修改。主要包括insert、update、deletet）操作。

比如在可重复读的隔离条件下，我开启了两个事务，在另一个事务中进行了插入操作，当前事务如果使用当前读 是可以读到最新的数据的。

MySQL中如何实现可重复读

当隔离级别为可重复读的时候，事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View。也就是说：对于A事务而言，不管其他事务怎么修改数据，对于A事务而言，它能看到的数据永远都是第一次SELECT时看到的数据。这显然不合理，如果其它事务插入了数据，A事务却只能看到过去的数据，读取不了当前的数据。

既然都说到 Read View 了，就不得不说 MVCC (多版本并发控制) 机制了。MVCC 其实字面意思还比较好理解，为了防止数据产生冲突，我们可以使用时间戳之类的来进行标识，不同的时间戳对应着不同的版本。比如你现在有1000元，你借给了张三 500 元，之后李四给了你 500 元，虽然你的钱的总额都是 1000元，但是其实已经和最开始的 1000元不一样了，为了判断中途是否有修改，我们就可以采用版本号来区分你的钱的变动。

如下，在数据库的数据表中，id，name，type 这三个字段是我自己建立的，但是除了这些字段，其实还有些隐藏字段是 MySQL 偷偷为我们添加的，我们通常是看不到这样的隐藏字段的。

我们重点关注这两个隐藏的字段：

db_trx_id：操作这行数据的事务 ID，也就是最后一个对该数据进行插入或更新的事务 ID。我们每开启一个事务，都会从数据库中获得一个事务 ID（也就是事务版本号），这个事务 ID 是自增长的，通过 ID 大小，我们就可以判断事务的时间顺序。
db_roll_ptr：回滚指针，指向这个记录的 Undo Log 信息。什么是 Undo Log 呢？可以这么理解，当我们需要修改某条记录时，MySQL 担心以后可能会撤销该修改，回退到之前的状态，所以在修改之前，先把当前的数据存个档，然后再进行修改，Undo Log 就可以理解为是这个存档文件。这就像是我们打游戏一样，打到某个关卡先存个档，然后继续往下一关挑战，如果下一关挑战失败，就回到之前的存档点，不至于从头开始。

在 MVCC（多版本并发控制）机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在 Undo Log 里。如下图所示，当前行记录的 回滚指针 指向的是它的上一个状态，它的上一个状态的回滚指针又指向了上一个状态的上一个状态。这样，理论上我们通过遍历 回滚指针，就能找到该行数据的任意一个状态。

Undo Log 示意图

我们没有想到，我们看到的或许只是一条数据，但是MySQL却在背后为该条数据存储多个版本，为这条数据存了非常多的档。那问题来了，当我们开启事务时，我们在事务中想要查询某条数据，但是每一条数据，都对应了非常多的版本，这时，我们需要读取哪个版本的行记录呢？

这时就需要用到 Read View 机制了，它帮我们解决了行的可见性问题。Read View 保存了当前事务开启时所有活跃（还没有提交）的事务列表。

在 Read VIew 中有几个重要的属性：

trx_ids，系统当前正在活跃的事务 ID 集合
low_limit_id，活跃的事务中最大的事务 ID
up_limit_id，活跃的事务中最小的事务 ID
creator_trx_id，创建这个 Read View 的事务 ID

在前面我们说过了，在每一行记录中有一个隐藏字段 db_trx_id，表示操作这行数据的事务 ID ，而且 事务 ID 是自增长的，通过 ID 大小，我们就可以判断事务的时间顺序。

当我们开启事务以后，准备查询某条记录，发现该条记录的 db_trx_id < up_limit_id，这说明什么呢？说明该条记录一定是在本次事务开启之前就已经提交的，对于当前事务而言，这属于历史数据，可见，因此，我们通过 select 一定能查出这一条记录。

但是如果发现，要查询的这条记录的 db_trx_id > up_limit_id。这说明什么呢，说明我在开启事务的时候，这条记录肯定是还没有的，是在之后这条记录才被创建的，不应该被当前事务看见，这时候我们就可以通过 回滚指针 + Undo Log 去找一下该记录的历史版本，返回给当前事务。在本文 什么是幻读？ 这一章节中举的一个例子。A 事务开启时，数据库中还没有（30, 30, 30）这条记录。A事务开启以后，B事务往数据库中插入了（30, 30, 30）这条记录，这时候，A事务使用 不加锁 的 select 进行 快照读 时是查询不出这条新插入的记录的，这符合我们的预期。对于 A事务而言，（30, 30, 30）这条记录的 db_trx_id 一定大于 A事务开启时的 up_limit_id，所以这条记录不应该被A事务看见。

如果需要查询的这条记录的 trx_id 满足 up_limit_id < trx_id < low_limit_id 这个条件，说明该行记录所在的事务 trx_id 在目前 creator_trx_id 这个事务创建的时候，可能还处于活跃的状态，因此我们需要在 trx_ids 集合中进行遍历，如果 trx_id 存在于 trx_ids 集合中，证明这个事务 trx_id 还处于活跃状态，不可见，如果该记录有 Undo Log，我们可以通过回滚指针进行遍历，查询该记录的历史版本数据。如果 trx_id 不存在于 trx_ids 集合中，证明事务 trx_id 已经提交了，该行记录可见。

从图中你能看到回滚指针将数据行的所有快照记录都通过链表的结构串联了起来，每个快照的记录都保存了当时的 db_trx_id，也是那个时间点操作这个数据的事务 ID。这样如果我们想要找历史快照，就可以通过遍历回滚指针的方式进行查找。

最后，再来强调一遍：事务只在第一次 SELECT 的时候会获取一次 Read View

因此，如下图所示，在 可重复读 的隔离条件下，在该事务中不管进行多少次 以WHERE heigh > 2.08为条件 的查询，最终结果得到都是一样的，尽管可能会有其它事务对这个结果集进行了更改。

如何解决幻读

即便是给每行数据都加上行锁，也无法解决幻读，行锁只能阻止修改，无法阻止数据的删除。而且新插入的数据，自然是数据库中不存在的数据，原本不存在的数据自然无法对其加锁，因此仅仅使用行锁是无法阻止别的事务插入数据的。

为了解决幻读问题，InnoDB 只好引入新的锁，也就是间隙锁(Gap Lock)。顾名思义，间隙锁，锁的就是两个值之间的空隙。比如文章开头的表 t，初始化插入了 6 个记录，这就产生了 7 个间隙。

表 t 主键索引上的行锁和间隙锁

也就是说这时候，在一行行扫描的过程中，不仅将给行加上了行锁，还给行两边的空隙，也加上了间隙锁。现在你知道了，数据行是可以加上锁的实体，数据行之间的间隙，也是可以加上锁的实体。但是间隙锁跟我们之前碰到过的锁都不太一样。

间隙锁和行锁合称 next-key lock，每个 next-key lock 是前开后闭区间。也就是说，我们的表 t 初始化以后，如果用 SELECT * FEOM t FOR UPDATE要把整个表所有记录锁起来，就形成了 7 个 next-key lock，分别是 (负无穷,0]、(0,5]、(5,10]、(10,15]、(15,20]、(20, 25]、(25, 正无穷]。
间隙锁是在可重复读隔离级别下才会生效的

怎么加间隙锁呢？使用写锁（又叫排它锁，X锁）时自动生效，也就是说我们执行 SELECT * FEOM t FOR UPDATE时便会自动触发间隙锁。会给主键加上上图所示的锁。

如下图所示，如果在事务A中执行了SELECT * FROM t WHERE d = 5 FOR UPDATE以后，事务B则无法插入数据了，因此就避免了产生幻读。

数据表的创建语句如下

CREATE TABLE `t` (`id` int(11) NOT NULL,`c` int(11) DEFAULT NULL,`d` int(11) DEFAULT NULL,PRIMARY KEY (`id`),KEY `c` (`c`) -- 创建索引
) ENGINE=InnoDB;INSERT INTO t VALUES(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);

需要注意的是，由于创建数据表的时候仅仅只在c字段上创建了索引，因此使用条件WHERE id = 5查找时是会扫描全表的。因此，SELECT * FROM t WHERE d = 5 FOR UPDATE实际上锁住了整个表，如上图所示，产生了七个间隙，这七个间隙都不允许数据的插入。

因此当B想插入一条数据(1, 1, 1)时就会被阻塞住，因为它的主键位于位于(0, 5]这个区间，被禁止插入。

还需要注意的一点是，间隙锁和间隙锁是不会产生冲突的。
读锁（又称共享锁，S锁）和写锁会冲突，写锁和写锁也会产生冲突。但是间隙锁和间隙锁是不会产生冲突的

如下：
A事务对id = 5的数据加了读锁，B事务再对id = 5的数据加写锁则会失败，若B事务加读锁则会成功。读锁和读锁可以兼容，读锁和写锁则不能兼容。

A事务对id = 5的数据加了写锁，B事务再对id = 5的数据加写锁则会失败，若B事务加读锁同样也会失败。

在加了间隙锁以后，当A事务开启以后，并对(5, 10]这个区间加了间隙锁，那么B事务则无法插入数据了。

但是当A事务对(5, 10]加了间隙锁以后，B事务也可以对这个区间加间隙锁。

间隙锁的目的是阻止往这个区间插入数据，因此A事务加了以后B事务继续加间隙锁，这并不矛盾。但是对于写锁和读锁就不一样了。
写锁是不允许其它事务读，也不允许写，而读锁则是允许写，语义上就存在冲突。自然无法同时加这两个锁。
而写锁和写锁也是，写锁不允许读，也不允许写，想想，A事务对数据加了写锁，就是完全不想让其它事务操作该数据，那其它数据若能为这个数据加写锁，就相当于是对该数据实施了操作，违背了写锁的涵义，自然不被允许。

参考
SQL必知必会陈旸
MySQL实战45讲林晓斌