洛阳电商网站建设,免费申请二级域名,低价网站建设推广优化,网店美工招聘文章目录 前言一、什么是幻读#xff1f;二、快照读是如何避免幻读的#xff1f;三、当前读是如何避免幻读的#xff1f;四、幻读被完全解决了吗#xff1f;场景1场景2 总结 前言
MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」#xff0c;但是它很大程度上避免幻读… 文章目录 前言一、什么是幻读二、快照读是如何避免幻读的三、当前读是如何避免幻读的四、幻读被完全解决了吗场景1场景2 总结 前言
MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」但是它很大程度上避免幻读现象并不是完全解决了解决的方案有两种
针对快照读普通 select 语句是通过 MVCC 方式解决了幻读因为可重复读隔离级别下事务执行过程中看到的数据一直跟这个事务启动时看到的数据是一致的即使中途有其他事务插入了一条数据是查询不出来这条数据的所以就很好了避免幻读问题。针对当前读select … for update 等语句是通过 next-key lock记录锁间隙锁方式解决了幻读因为当执行 select … for update 语句的时候会加上 next-key lock如果有其他事务在 next-key lock 锁范围内插入了一条记录那么这个插入语句就会被阻塞无法成功插入所以就很好了避免幻读问题。
这两个解决方案是很大程度上解决了幻读现象但是还是有个别的情况造成的幻读现象是无法解决的。
一、什么是幻读
首先来看看 MySQL 文档是怎么定义幻读Phantom Read的: The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row. 翻译当同一个查询在不同的时间产生不同的结果集时事务中就会出现所谓的幻象问题。例如如果 SELECT 执行了两次但第二次返回了第一次没有返回的行则该行是“幻像”行。
举个例子假设一个事务在 T1 时刻和 T2 时刻分别执行了下面查询语句途中没有执行其他语句
SELECT * FROM t_test WHERE id 100;只要 T1 和 T2 时刻执行产生的结果集是不相同的那就发生了幻读的问题比如
T1 时间执行的结果是有 5 条行记录而 T2 时间执行的结果是有 6 条行记录那就发生了幻读。T1 时间执行的结果是有 5 条行记录而 T2 时间执行的结果是有 4 条行记录也是发生了幻读。
二、快照读是如何避免幻读的
可重复读隔离级是由 MVCC多版本并发控制实现的实现的方式是开始事务后执行 begin 语句后在执行第一个查询语句后会创建一个 Read View后续的查询语句利用这个 Read View通过这个 Read View 就可以在 undo log 版本链找到事务开始时的数据所以事务过程中每次查询的数据都是一样的即使中途有其他事务插入了新纪录是查询不出来这条数据的所以就很好了避免幻读问题。
做个实验数据库表 t_stu 如下其中 id 为主键。
然后在可重复读隔离级别下有两个事务的执行顺序如下 从这个实验结果可以看到即使事务 B 中途插入了一条记录事务 A 前后两次查询的结果集都是一样的并没有出现所谓的幻读现象。
三、当前读是如何避免幻读的
MySQL 里除了普通查询是快照读其他都是当前读比如 update、insert、delete这些语句执行前都会查询最新版本的数据然后再做进一步的操作。
这很好理解假设你要 update 一个记录另一个事务已经 delete 这条记录并且提交事务了这样不是会产生冲突吗所以 update 的时候肯定要知道最新的数据。
另外select … for update 这种查询语句是当前读每次执行的时候都是读取最新的数据。
接下来我们假设select … for update当前读是不会加锁的实际上是会加锁的在做一遍实验。 这时候事务 B 插入的记录就会被事务 A 的第二条查询语句查询到因为是当前读这样就会出现前后两次查询的结果集合不一样这就出现了幻读。
所以Innodb 引擎为了解决「可重复读」隔离级别使用「当前读」而造成的幻读问题就引出了间隙锁。
假设表中有一个范围 id 为35间隙锁那么其他事务就无法插入 id 4 这条记录了这样就有效的防止幻读现象的发生。 举个具体例子场景如下 事务 A 执行了这面这条锁定读语句后就在对表中的记录加上 id 范围为 (2, ∞] 的 next-key locknext-key lock 是间隙锁记录锁的组合。
然后事务 B 在执行插入语句的时候判断到插入的位置被事务 A 加了 next-key lock于是事物 B 会生成一个插入意向锁同时进入等待状态直到事务 A 提交了事务。这就避免了由于事务 B 插入新记录而导致事务 A 发生幻读的现象。
四、幻读被完全解决了吗
场景1
下面是一个幻读的场景依序号执行操作 这是因为操作7是一个当前读而当前读都是读取到的最新的数据所以客户端2在事务中提交的数据可以被看到发生了幻读 场景2
下面也是一个幻读的场景依序号进行操作 对于操作三我们先查询 id5 的数据发现没有然后再通过客户端提交一个插入 id5 的事务这是我们进行操作六发现查询不到数据但是却能更新而更新后就能查到了
这是一个匪夷所思的现象我们试着分析一下原因
在可重复读隔离级别下事务 A 第一次执行普通的 select 语句时生成了一个 ReadView之后事务 B 向表中新插入了一条 id 5 的记录并提交。接着事务 A 对 id 5 这条记录进行了更新操作在这个时刻这条新记录的 trx_id 隐藏列的值就变成了事务 A 的事务 id此时trx_id和ReadView中的creator_trx_id相同表示当前存在它自己修改过的记录所以这条记录可以被获取之后事务 A 再使用普通 select 语句去查询这条记录时就可以看到这条记录了于是就发生了幻读。
用到的规则如下上述规则出自《資料庫解剖學:從內部深解MySQL運作原理》 对应源码可以证明规则1 下面的例子可以验证上述规则1 总结
上面两种场景可以总结为一种情况那就是先进行快照读再插入然后执行当前读比如 update、insert、delete、select…lock in share mode (共享读锁)、select…for update等操作时会读取到最新的数据所以会出现幻读。
要避免这类特殊场景下发生幻读的现象的话就是尽量在开启事务之后马上执行 select … for update 这类当前读的语句因为它会对记录加 next-key lock从而避免其他事务插入一条新记录。
