面试必备——MySQL解决幻读的底层实现原理

1 问题背景

电商项目中并发太高，出现过好几次MySQL等待锁超时的生产级别报错。无论是对业务还是性能，都有很大的隐患。前天看到过一篇“面试官问可重复读级别下还会有幻读吗？”，笔者没能准确确定，以前研究过InnoDB存储架构以及MVCC，思绪很乱，今天写篇博客做下研究。

参考自：

1. Mysql 间隙锁原理，以及Repeatable Read隔离级别下可以防止幻读原理
2. Mysql innodb 间隙锁: 删除不存在的记录会产生间隙锁

2 前言

1. 本篇的理论知识偏多会略显枯燥，但这也是解决电商项目高并发的关键理论知识
2. 笔者旨在将MVCC以及锁这些知识串通起来，使得更加系统，同时也理顺自己混乱的思绪。
3. 建议先阅读笔者写的InnoDB锁和事务模型之锁、MySQL锁之InnoDB锁实战、面试必备——MySQL的MVCC实现原理，简单阅读了解个大概即可

3 间隙锁简介

由于写写并发操作的场景下会涉及间隙锁，因此在这里简要介绍间隙锁，下文也会提到它。

InnoDB支持3种行锁如下，详情可以见InnoDB锁和事务模型之锁

• 行锁（Record Lock）：锁是直接加在索引上，锁住的是key
• 间隙锁（Gap Lock）：锁定索引记录间隙，确保索引记录的间隙不变。间隙锁只针对事务隔离级别为可重复读隔离级别或以上级别
• Next-Key Lock：行锁和间隙锁组合起来就叫Next-Key Lock

4 MySQL底层是如何解决幻读？

有并发才会有可能产生幻读，而并发场景只有2种：读写操作；写写操作。

4.1 读写操作

通过MVCC机制实现。InnoDB仍能通过构建记录的旧版本信息来呈现查询结果。

可重复读隔离级别（RR）与读已提交隔离级别（RC）建立快照的时机是不同的。
（1）RR级别只在第一次查询建立快照，因此即使其他写操作的事务提交了事务，读操作的事务仍能看到第一次查询的结果。RR级别解决了幻读的现象。
（2）RC级别每一次查询 都会建立快照。因此其他写操作的事务提交了事务后，读操作的事务进行读取会再一次构建快照，那么就能看到写操作的事务修改的结果，因此会有幻读的现象。

4.2 写写操作

通过锁实现。官方文档指出：
（1）默认情况下，InnoDB在可重复读隔离级别运行，在这种情况下，InnoDB采用Next-Key锁进行搜索和扫描，以防止幻行。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁，再对索引记录两边的间隙加上间隙锁。加上间隙锁之后就不能在这个间隙修改或者插入记录。如果检索条件命中唯一索引（不包含多列唯一索引），则锁定的是行，没有间隙锁。
（2）如果将事务隔离级别更改成读已提交，间隙锁是被显示地禁用的。

5 真实案例

下面是复现电商项目中生产级别的死锁场景，如果图片模糊可以右击图片在新标签页打开：

解决方案：
方案一：删除操作尽量根据唯一索引去删除，比如where id = xxx，这样InnoDB就不会加间隙锁，只会锁住该条索引。
方案二：降低事务隔离级别，用读已提交隔离级别，该级别会显示禁用间隙锁。但是这个方案要慎用。