MySQL的InnoDB引擎是如何解决幻读的？

目录

幻读原因

InnoDB 的三种行锁

InnoDB 的解决方案

总结

面试题

---

在 MySQL 中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，只要提升隔离级别到串行化即可解决幻读问题。

本文结束！

---

串行化的隔离级别使数据库无法并发，那么，实际情况是如何解决幻读问题的呢？

幻读原因

在MVCC一文中，我们了解到数据库的MVCC机制，当隔离级别为读已提交（Read Commit）时一个事务中的每一次 SELECT 查询都会获取一次 Read View，如果 Read View 不同，就可能产生不可重复读或者幻读的情况：

事务	说明
BEGIN;
SELECT．．．	获取Read View
.................
SELECT．．．	获取Read View
COMMIT;

隔离级别为可重复读的时候，就避免了不可重复读，因为一个事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View。

 

InnoDB 的三种行锁

1. 记录锁：针对单个行记录添加锁。
2. 间隙锁（Gap Locking）：可以帮我们锁住一个范围（索引之间的空隙），但不包括记录本身。采用间隙锁的方式可以防止幻读情况的产生。
3. Next-Key 锁：帮我们锁住一个范围，同时锁定记录本身，相当于间隙锁 + 记录锁，可以解决幻读的问题。

出现幻读的原因是在读已提交的情况下，InnoDB 只采用记录锁（Record Locking）！

 

InnoDB 的解决方案

实际上，还是将锁的范围扩大到　间隙锁 + 记录锁　来解决幻读问题的。

在隔离级别为可重复读时，InnoDB 会采用 Next-Key 锁的机制，解决幻读问题。

 

总结

MySQL8以上版本默认隔离级别就是可重复读，是不存在事务问题的。

但是在高并发环境下可以手动降低隔离级别提高并发性。

---

面试题

T1 select 之后 update，会将 T2 中 insert 的数据一起更新，那么认为多出来一行，所以防不住幻读，对吗？

答案：
错误，InnoDB 中设置了快照读和当前读两种模式，如果只有快照读，那么自然没有幻读问题，但是如果将语句提升到当前读，那么 T1 在 select 的时候需要用如下语法： select * from t for update (lock in share mode) 进入当前读，那么自然没有 T2 可以插入数据这一回事儿了

 

参考：https://blog.csdn.net/mrs_chens/article/details/90644868