18.mysql深入解读幻读

幻读!幻读!!幻读!!!幻TMD读!!!!!!

真的把我搞晕了,为了不让其他未来之星看到幻读头大,我这里要把幻读搞得明明白白,给大家看!(虽然现在是凌晨了...)

概念:
事务A的两次读之间有其他事务写操作，比如事务A统计年龄 > 30，当A两次读数据之间其他事务新添加了记录，
所以事务A第二次读取到的数据突然多了一个，仿佛出现了幻觉一般，这就是一种幻读

那么mysql是怎么解决幻读呢:

1. 快照读(snapshot read)

假如有一张表,有6条数据,我们有两个会话session,分别开启了A,B两个事务:当你执行select *之后，在A与B事务中都会返回6条一样的数据:

当执行select的时候，innodb默认会执行快照读，相当于就是给你目前的状态照了一张照片，同一个事务里以后执行select 的时候就会返回当前照片里面的数据，当其他事务提交了也对你不造成影响，和你没关系，这就实现了可重复读了，那这个照片是什么时候生成的呢？不是开启事务的时候，是当你第一次执行select的时候，也就是说，当A开启了事务，然后没有执行任何操作，这时候B insert了一条数据然后commit,这时候A执行 select，那么返回的数据中就会有B添加的那条数据......之后无论再有其他事务commit都没有关系，因为照片已经生成了，而且不会再生成了，以后都会参考这张照片。

 有哪些是快照读语句:

简单的select操作(不包括 select ... lock in share mode, select ... for update);

所以,在快照读的时候是不可能产生幻读的!这种情形下是通过MVCC的快照保证的。(MVCC快照原理在文章下面会有说明)

2.当前读(current read)

也就是会读取最新的记录，也就是别的事务提交的数据你也可以看到，假设你要update一个记录，另一个事务已经delete这条数据并且commit了，这样如果我们继续update肯定产生冲突，所以你update的时候肯定要读到的是最新的信息。

当前读包含哪些语句:

select ... lock in share mode

select ... for update

insert...

update...

delete...

最后的结论:

MySQL RR(可重复读隔离级别)下，如果没有当前读，它不会产生幻读，这种情形下是通过MVCC的快照保证的。

如果存在当前读，那么可能会产生幻读。这种幻读一般会在一个快照读跟着一个当前读的时候(例如上面的例子)发生，想避免这种情形，要么对所有的读都加锁，要么就是增加隔离级别到 serializable。

当然,上面所说的加锁并不是我们自己加:

对于UPDATE、DELETE和INSERT语句(所有的当前读)，InnoDB会自动给涉及数据集加排他锁（X)；

对于普通SELECT语句，InnoDB不会加任何锁；

可以通过以下语句显式给记录加共享锁或排他锁 。

共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他锁（X) ：SELECT * FROM table_name WHERE ... FOR UPDATE

所以上面的例子解决方案就是第一步读取数据我们也使用当前读:

 select * from test_innodb_lock  for update;

这样,其他事务就不可以对我们查询范围内的数据做相关更新了:

B事务:

A事务:

 

 直到B事务执行完所有操作提交事务后,A才可以操作;

mysql实现上述功能使用了两种锁:

关于锁,不熟悉的可以先参考:https://www.cnblogs.com/luzhanshi/p/13405869.html

行锁:

InnoDB 实现了以下两种类型的行锁。

• 共享锁（S）：又称为读锁，简称S锁，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。

• 排他锁（X）：又称为写锁，简称X锁，排他锁就是不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。

对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；

间隙锁:

当我们用范围条件，而不是使用相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据进行加锁； 对于键值在条件范围内但并不存在的记录，叫做 "间隙（GAP）" ， InnoDB也会对这个 "间隙" 加锁，这种锁机制就是所谓的 间隙锁（Next-Key锁） 。

例如:

update table set name='王者荣耀李白攻略' where id>100;
由于是update语句,所有mysql会自动添加排它锁,而这次请求的排它锁会添加到id>100所有的数据上

Next-Key Lock会确定一段范围，然后对这个范围加锁，保证A事务在where的条件下操作的数据是一致的，因为在where这个范围其他事务根本插不了也删不了数据，都被Next-Key Lock锁堵在一边阻塞掉了。

MVCC原理:

多版本并发MVCC：

InnoDB 的 MVCC， 是 通过 在 每 行 记录 后面 保存 两个 隐藏 的 列 来 实现 的。 这 两个 列， 一个 保存 了 行的 创建 时间， 一个 保存 行的 过期 时间（ 或 删除 时间）。 当然 存储 的 并不是 实际 的 时间 值， 而是 系统 版 本号（ system version number）。 每 开始 一个 新的 事务， 系统 版本 号 都会 自动 递增。 事务 开始时 刻 的 系统 版 本号 会 作为 事务 的 版 本号， 用来 和 查询 到 的 每 行 记录 的 版本 号 进行 比较。

MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个 隔离 级别 下 工作。

MVCC快照读需满足条件：

1. InnoDB 只 查找 版本 早于 当前 事务 版本 的 数据 行（ 也就是， 行的 系统 版本 号 小于 或 等于 事务 的 系统 版 本号）， 这样 可以 确保 事务 读 取的 行， 要么 是在 事务 开始 前 已经 存在 的， 要么 是 事务 自身 插入 或者 修 改过 的。
2. 行的 删除 版本 要么 未定义， 要么 大于 当前 事务 版 本号。 这可 以 确保 事务 读取 到 的 行， 在 事务 开始 之前 未被 删除。

MVCC解决了基于快照读下的幻读，事务 读 取的 行， 要么 是在 事务 开始 前 已经 存在 的， 要么 是 事务 自身 插入 或者 修 改过 的。

并不会读到其他事务的写操作 ！！！