MySQL 幻读-Toy模板网

这篇具有很好参考价值的文章主要介绍了MySQL 幻读。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

什么是幻读？

假设这样一个场景：

MySQL 幻读

对于T3 查到的（0，0，5）不是幻读，T5查到的（1，1，5）才是幻读。（ 幻读仅专指“新插入的行 ）

注：上面的图并不会实际发生，只是为了更好的引出问题而写的，实际上MySQL已经针对幻读问题做了解决方案（next-key lock下面讲），实际情况T5不会查到新插入的数据。

官方定义：当同一个查询在不同的时间产生不同的结果集时，事务中就会出现所谓的幻象问题。例如，如果 SELECT 执行了两次，但第二次返回了第一次没有返回的行，则该行是“幻像”行。

这三个查询都是加了 for update，都是当前读。而当前读的规则，就是要能读到所有已经提交的记录的最新值。所以才会出现幻读的情况，查到新插入的记录

针对MySQL的幻读，在默认隔离级别是可重读下，有以下两种解决方案：

当前读，通过MVCC 方式解决了幻读，在默认隔离级别可重复读下，一个事务启动后快照读的数据和启动时刻所有的数据是一致的，即使中途有其他事务插入了一条数据，也查不出来这一条数据，所有避免了幻读问题
当前读，虽然上面说了幻读发生在当前读，但MySQL 通过next-key lock（记录锁+间隙锁）解决了，当执行select … for update 语句的时候，会加上next-key lock （在一个区间内加锁），如果有其它事务在这个范围内插入一条数据，那么这个插入就会被阻塞，无法插入，所以就避免了幻读问题。

虽然上面两个方案很好的解决了幻读问题，但还是有个别情况幻读现象无法解决，这就是我们接下来要讨论的问题。

快照读是如何避免幻读的？

我们在可重复读隔离级别下讨论快照读，可重复读是由MVCC（多并发版本控制）实现的，在事务启动后，在执行第一个语句时，会创建一个Read View，后续的快照读查询语句都是利用这个ReadView视图来获取数据的（通过undo log 版本链找到事务开始时的数据），使用事务过程中每次快照读的数据都是一致的。
MySQL 幻读
从这个试验中可以看出，我们在事务B插入数据，但事务A的查询集并没有变，所有没有出现幻读，也说明了快照读解决了幻读问题。

当前读是如何避免幻读的？

除了普通快照读都是当前读，比如 update，insert，delete，select … for update，select … lock in share mode。每次读都会获取最新的数据

接下来，我们假设select … for update 当前读是不加锁的（实际加锁），看看会发生什么？

MySQL 幻读

这个时候事务A 会查询到事务B新插入的数据（因为是当前读，所以查最新），这样就会出现前后两次查询的结果集合不一样，就出现了幻读。

所以，Innodb引擎为了解决可重复读隔离界别下使用当前读而造成的幻读问题，就引入了间隙锁。

假设。表中有一个范围id 为（3,5）间隙锁，那么其它事务就无法插入id=4的记录了，这样就有效的防止幻读现象的发生。
MySQL 幻读
再来看个具体例子：

事务A 执行了这面这条语句后，就在对表中的记录加上 id 范围为 (2, +∞] 的 next-key lock（next-key lock 是间隙锁+记录锁的组合）。

然后事务B插入语句是，会判断插入的位置被加了next-key lock，于是事务B会生成一个插入意向锁（这个锁没有说明实际意义，只是作为一个标记），同时进入等待状态，直到事务A 提交了事务，插入语句才会执行。这样就避免了由于事务B 插入新记录而导致事务A 发生幻读的现象。

幻读被完全解决了吗？没有！

第一个发生幻读的场景

可重复读隔离级别下虽然很大程度上避免了幻读，但是还是没有能完全解决幻读。

接下来的例子好好看！！！
有一张这样的表：
MySQL 幻读
事务A先查询id=5，什么也查不到，因为没有这条数据
快照读，不会加next-key lock 锁

# 事务 A
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t_stu where id = 5;
Empty set (0.01 sec)

然后事务B 插入一条语句并提交
因为上面的查询语句没有加锁，所以这里不会阻塞，直接插入成功。

# 事务 B
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t_stu values(5, '小美', 18);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

到现在为止，你也应该看得懂，查询也没有问题，下面是关键一步：
事务A更新id=5 的记录，虽然事务A看不到 id=5 这条记录，但是它确实去更新了，有点违和，但是接下来事务A再去查询就能看到id=5 的记录了，幻读就这样发生了

# 事务 A
mysql> update t_stu set name = '小林coding' where id = 5;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from t_stu where id = 5;
+----+--------------+------+
| id | name         | age  |
+----+--------------+------+
|  5 | 小林coding   |   18 |
+----+--------------+------+
1 row in set (0.00 sec)

如果不太明白就看一看下面的图：
MySQL 幻读
在可重复读隔离级别，事务A的第一次查询生成了 ReadView，快照读也确实去读的这个视图，之后事务B插入id=5的记录。接着，事务A对id=5更新操作的时候，用到了当前读，此时会有next-key lock锁，但是数据已经插入了，所以这个锁也就没有用了，这条新记录的 trx_id 隐藏列的值就变成了事务 A 的事务 id，之后事务 A 再使用普通 select 语句去查询这条记录时就可以看到这条记录了，于是就发生了幻读。

所以MySQL InnoDB中的MVCC 并不能完全避免幻读现象

第二个发生幻读的场景

T1时刻，事务 A 先执行「快照读语句」：select * from t_test where id > 100 得到了 3 条记录。
T2时刻：事务 B 往插入一个 id= 200 的记录并提交；
T3时刻：事务 A 再执行「当前读语句」 select * from t_test where id > 100 for update 就会得到 4 条记录，此时也发生了幻读现象。

要避免这类特殊场景发生幻读的话，就尽量在开启事务之后，马上执行 select … for update 对记录进行 next-key lock 加锁，避免另一个书屋插入一条新数据