The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times.，这句话看起来应该是不可重复读的定义，同样的查询得到了不同的结果(两次结果不是重复的)，但是后面的举例给出了幻读真正的定义，第二次比第一次多出了一行。也就是说，幻读的出现有这样一个前提，第二次查询前其他事务提交了一个INSERT插入语句。而不可重复读出现的前提是第二次查询前其他事务提交了UPDATE或者DELETE操作。
mysql的快照读，使得在RR的隔离级别上在next-Key的作用区间内，制造了一个快照副本，这个副本是隔离的，无论副本对应的区间里的数据被其他事务如何修改，在当前事务中，取到的数据永远是副本中的数据。
RR级别下之所以可以读到之前版本的数据，是由于数据库的MVCC(Multi-Version Concurrency Control，多版本并发控制)。参见InnoDB Multi-Versioning
有些文章中提到“RR也不能完全避免幻读”，实际上官方文档实际要表达的意义是“在同一个事务内，多次连续查询的结果是一样的，不会因其他事务的修改而导致不同的查询结果”，这里先给出实验结论：
1.当前事务如果未发生更新操作(增删改)，快照版本会保持不变，多次查询读取的副本是同一个。
2.当前事务如果发生更新(增删改)，再次查询时，会刷新快照版本。
RC情况下会出现幻读。
首先设置隔离级别为RC,SET SESSION tx_isolation='READ-COMMITTED';
mysql> SET SESSION tx_isolation='READ-COMMITTED';
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test values(9,9);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 9 | 9 |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec)
RC(Read Commit)隔离级别可以避免脏读，事务内无法获取其他事务未提交的变更，但是由于能够读到已经提交的事务，因此会出现幻读和不重复读。
也就是说，RC的快照读是读取最新版本数据，而RR的快照读是读取被next-key锁作用区域的副本
我们先来模拟一下RR隔离级别下没有出现幻读的情况：
开启第一个事务并执行一次快照查询。
事务一事务二mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test values(9,9);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec)
这两个事务的执行，有两个问题：
1.为什么之前的例子中，在第二个事务的INSERT被阻塞了，而这次却执行成功了。
这是因为原来的语句中带有for update，这种读取是当前读，会加锁。而本次第一个事务中的SELECT仅仅是快照读，没有加任何锁。所以不会阻塞其他的插入。
2.数据库中的数据已经改变，为什么会读不到？
这个就是之前提到的next-key lock锁定的副本。RC及以下级别才会读到已经提交的事务。更多的业务逻辑是希望在某段时间内或者某个特定的逻辑区间中，前后查询到的数据是一致的，当前事务是和其他事务隔离的。这也是数据库在设计实现时遵循的ACID原则。
再给出RR条件下出现幻读的情形，这种情形不需要两个事务，一个事务就已经可以说明，
mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from test where id>8; +----+------+ | id | code | +----+------+ | 10 | 10 | +----+------+ 1 row in set (0.00 sec) mysql> update test set code=9 where id=10; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from test where id>8; +----+------+ | id | code | +----+------+ | 10 | 9 | +----+------+ 1 row in set (0.00 sec)