关于innodb下，幻读是如何被解决的

1、MVCC 多版本并发控制（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。 基本思想 在封锁一节中提到，加锁...

InnoDB默认的隔离级别是RR（可重复读），可以解决脏读和不可重复读，只解决了快照读情况下的幻读问题,当前读情况下解决幻读问题得靠next-key锁。 mysql如何实现避免幻读: 在快照读读情况下，mysql通过mvcc来避免幻读。 在当前读读情况下，mysql通过next-key来避免幻读 - 快照读, 读取专门的快照 (对于RC，快照（ReadView）会在每个语句中创建。对于RR...

MySQL多版本并发控制事务的ACID事务的隔离级别锁锁粒度多版本并发控制(MVCC)SELECTINSERTDELETEUPDATE可重复读下，MVCC的幻读问题读操作不会出现幻读更新操作会出现幻读问题这种现象的原因快照读当前读如何解决当前读导致的幻读问题使用可串行化的隔离级别使用next-key锁，即更新时基于非唯一索引更新数据 事务的ACID 原子性：整个事务中的所有操作要么全部提交成功，要么全部失败回滚； 一致性：总是从一个一致性的状态转换到另外一个一致性的状态，无中间状态； 隔离性：一个事务所做

通过 MVCC 的一致性视图屏蔽其他事务的修改和插入（无幻读）。

前言大部分人在日常的业务开发中，其实很少去关注数据库的事务相关问题，基本上都是 CURD 一把梭。正好最近在看 MySQL 的相关基础知识，其中对于幻读问题之前一直没有理解深刻，今天就来聊聊「InnoDB 是如何解决幻读的」，话不多说，下面进入主题。事务隔离级别事务隔离是数据库处理的基础之一，是ACID[1]中的I。在 MySQL 的 InnoDB 引擎中支持在SQL:1992[2]标准...

幻读是指在一个事务中，多次读取相同范围的数据时，由于其他事务的插入操作，导致读取到的结果集发生变化。事务 A 查询age > 20的用户，得到 5 条记录。事务 B 插入一条age = 25的记录并提交。事务 A 再次查询age > 20，得到 6 条记录。这种“凭空多出”的记录就是幻读。幻读不同于脏读（未提交数据）和不可重复读（同一行数据变化），它涉及范围查询的结果集变化。当前读读取的是最新数据，通常涉及写操作或显式加锁。

在MySQL中，InnoDB存储引擎支持四种事务隔离级别，分别是：读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）、可重复读（REPEATABLE READ）和串行化（SERIALIZABLE）。MVCC是一种用于管理数据库并发访问的技术，它通过为每个事务提供一个一致的视图，确保在高并发环境下，事务可以独立地进行读写操作而不会相互干扰。Next-Key Lock是InnoDB在可重复读和串行化隔离级别下使用的一种锁机制，它结合了记录锁和间隙锁。

目录 幻读原因 InnoDB 的三种行锁 InnoDB 的解决方案 总结 面试题 在 MySQL 中，默认的隔离级别是可重复读，可以解决脏读和不可重复读的问题，只要提升隔离级别到串行化即可解决幻读问题。 本文结束！ 串行化的隔离级别使数据库无法并发，那么，实际情况是如何解决幻读问题的呢？ 幻读原因 在MVCC一文中，我们了解到数据库的MVCC机制，当隔离级别为读已提交（Read Commit）时一个事务中的每一次 SELECT 查询都会获取一次 Read View，如果 Read Vie

结论 首先说结论，在RR的隔离级别下，Innodb使用MVCC和next-key locks解决幻读，MVCC解决的是普通读（快照读）的幻读，next-key locks解决的是当前读情况下的幻读。 幻读是什么 事务A，先执行： update table set name=“hh” where id>3; 结果为： OK row xx 表名成功影响多少行数据 事务B，后执行，并且提交： insert into table values(11, uu); commit; 事务A，然后再selec

本文在探讨InnoDB是否真正意义上解决幻读需要相关的前置知识InnoDB中的事务隔离级别和锁的关系搞懂MySQL的MVCC。

无特别说明，本文都是RR 隔离级别，因为间隙锁在RR下才生效。若设置为RC，就没间隙锁。但同时，要解决可能出现的数据和日志不一致问题，要把binlog格式设为row。这也是互联网常用配置。若RC够用，即业务无需保证RR，考虑到RC下的操作数据的锁范围更小（无间隙锁），选择RC就是合适的。若都用RC，可逻辑备份时，mysqldump为何要把备份线程设置成RR？然后，在备份期间，备份线程用RR，而业务线程用RC。同时存在两种事务隔离级别，会有问题吗？即使给所有行加上行锁，仍无法解决幻读，因此引入间隙锁。

next-key Lock 相当于间隙锁和记录锁的合集，记录锁锁定存在的记录行，间隙锁锁住 记录行之间的间隙，而 next-key Lock 锁住的是两者之和。间隙锁和 next-key Lock 的区别在于加锁的范围，间隙锁只锁定两个索引之间的引用间 隙，而 next-key Lock 会锁定多个索引区间，它包含记录锁和间隙锁。注意，这里强调的是范围查询， 也就是说，InnoDB 引擎要解决幻读问题，必须要保证一个点，就是如果一个事务通过 这样一条语句（如图）进行锁定时。

参考文档：https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html。 InnoDB是一种多版本（multi-version）存储引擎，支持事务。很多书籍、资料中都说MVCC解决了幻读的问题，NO，其实MVCC并没有解决幻读问题。MVCC只是通过undo log解决了RR事务隔离级别中的consitent read问题...

InnoDB通过锁机制和多版本并发控制（MVCC）有效解决了脏读、不可重复读和幻读等并发问题。理解这些机制的工作原理和实际应用，对于提升数据库操作的效率和可靠性至关重要。通过本文的讲解，希望你能够更深入地理解InnoDB如何解决脏读、不可重复读和幻读，并在实际工作中应用这些知识，提升数据库操作的效率和可靠性。如果你有任何问题或需要进一步的帮助，请在评论区留言，我会尽力为你解答。

在数据库系统中，幻读（Phantom Read）是指在一个事务中，两次读取同一范围的数据集时，由于其他事务的插入操作，导致第二次读取结果集发生变化的问题。InnoDB 作为 MySQL 的一个存储引擎，通过多种机制来解决幻读问题，主要包括锁机制和隔离级别。

1. 结论 首先说结论，在RR的隔离级别下，Innodb使用MVCC和next-key locks解决幻读，MVCC解决的是普通读（快照读）的幻读，next-key locks解决的是当前读情况下的幻读。 2. 幻读是什么 事务A，先执行： updatetablesetname=“hh”whereid>3; 结果为： OK row xx 表名成功影响多少行数据 事务B，后执行，并且提交： insertintotable...