MySql默认的隔离级别为Repeatable Read(可重复读)，因此只会出现幻读的情况。
幻读（侧重于操作的失败）
A第一次读的时候不存在，然后B插入数据，A再插入就出错了（因为B插入了）。读前写后。
select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。
不可重复读（侧重于读取的不同）
同样的条件，你读取过的数据，再次读取出来发现值不一样了。
在一个事务中前后两次读取的结果并不致，导致了不可重复读。
MVCC是如何解决幻
实际上mvcc解决了读数据情况下的幻读问题。而对于修改的操作依旧存在幻读问题，就是说MVCC对于幻读的解决时不彻底的。
MVCC实现是不同的，典型的有乐观（optimistic）并发控制控制和悲观（pessimistic）并发控制。
是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号。
SELECT InnoDB会根据以下两个条件检查每行记录：InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。只有符合上述两个条件的记录，才能返回作为查询结果。
INSERT InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。MVCC只在REPEATABLEREAD和READCOMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容(4)，因为READUNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。
RR级
# 这里需要用 X锁， 用 LOCK IN SHARE MODE 拿到 S锁 后我们没办法做 写操作SELECT`id`FROM`users`WHERE`id`=1FORUPDATE;
给行加锁的同时，是给索引加锁。
SERIALIZABLE级别杜绝幻读
在此级别下，我们便不需要对 SELECT 操作显式加锁，InnoDB会自动加锁，事务安全，但性能很低.
