InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现。这两个列，一个保存了行的创建时间，一个保存行的删除时间，并不是实际的世界，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号作比较，MVCC只在可重读读和提交读两种隔离级别下工作。

可重复读下的MVCC的操作方法

SELECT

InnoDB会根据以下两个条件检查每行记录：

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

只有符合上述两个条件的记录，才能返回作为查询结果。

INSERT

InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE

InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE

InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

可重复读下，MVCC的幻读问题

读操作不会出现幻读

关闭自动提交事务

SET AUTOCOMMIT = 0;

新增测试表测试数据
在这里插入图片描述
开启事务A，读取到两条测试数据
此时读取到原有的两条测试数据
开启事务B，插入数据并提交

事务A再次读取仍为两条数据，没有出现幻读，注意不要执行begin，单独执行查询，否则开启了新的事务
在这里插入图片描述

更新操作会出现幻读问题

在测试表上新增一个测试字段，测试表和测试数据在这里插入图片描述
开启事务A，更新数据，受影响行数3条

开启事务B，插入数据并提交

事务A再次更新数据，却仍然影响了事务B插入的数据，出现幻读，注意不要执行begin，单独执行更新，否则新开启了事务

这种现象的原因

快照读

当执行select操作是innodb默认会执行快照读，会记录下这次select后的结果，之后select 的时候就会返回这次快照的数据，即使其他事务提交了不会影响当前select的数据，这就实现了可重复读了。快照的生成当在第一次执行select的时候，也就是说假设当A开启了事务，然后没有执行任何操作，这时候B insert了一条数据然后commit,这时候A执行 select，那么返回的数据中就会有B添加的那条数据。之后无论再有其他事务commit都没有关系，因为快照已经生成了，后面的select都是根据快照来的。

当前读

对于会对数据修改的操作(update、insert、delete)都是采用当前读的模式。在执行这几个操作时会读取最新的版本号记录，写操作后把版本号改为了当前事务的版本号，所以即使是别的事务提交的数据也可以查询到。假设要update一条记录，但是在另一个事务中已经delete掉这条数据并且commit了，如果update就会产生冲突，所以在update的时候需要知道最新的数据。也正是因为这样所以才导致幻读。

在快照读情况下，MySQL通过mvcc来避免幻读。
在当前读情况下，MySQL通过next-key来避免幻读

如何解决当前读导致的幻读问题

使用可串行化的隔离级别

SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁竞争的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别

使用next-key锁，即更新时基于非唯一索引更新数据

InnoDB中next-key基于行锁和间隙锁实现，而间隙锁依赖于非唯一索引，InnoDB中索引是有序的，间隙锁时基于索引锁住其他事务需要插入的索引行，当使用非唯一索引进行更新时InnoDB会加上间隙锁，阻塞其他事务需要查询的索引行，避免幻读

新增非唯一索引

ALTER TABLE tb_user ADD INDEX idx_batch(batch);

开启事务A，更新数据，受影响行数3条
在这里插入图片描述
开始事务B插入数据，此时由于next-key锁存在，插入被阻塞

事务A查询数据，仍然为3条数据

所以在InnoDB中，在可重复读隔离级别中，MVCC可防止快照读引起的幻读，next-key锁可防止当前读引起的幻读

InnoDB基于MVCC和next-key锁解决幻读问题