很好的总结，谢谢。很多人由于看到innodb的RR级别不发生幻读，所以就以为sql标准中RR是不发生幻读的，甚至有些搞培训的都这么认为！

maybe you try it like this

@xiaoma20082008
所以这样还是没法避免 幻读的情况对吧，
但是之前博主的博客，不是说 select * from t where a = 1;
虽然a不是主键，也不存在唯一索引，但是会对a 符合条件的行 加上gap锁么？
这样事务2应该会阻塞，而不是update成功才对，事务1也不会读到事务2的更新才是

@jonwinters，@xiaoma20082008 举的例子中，第一次的"select * from t where a = 1"是快照读，而不是当前读，所以是不会加锁的，事务2也不会阻塞。但是我认为这个例子反映的并不是幻读的问题。
引用MySQL 加锁处理分析里的定义：

所谓幻读，就是同一个事务，连续做两次当前读 (例如：select * from t1 where id = 10 for update;)，那么这两次当前读返回的是完全相同的记录 (记录数量一致，记录本身也一致)，第二次的当前读，不会比第一次返回更多的记录 (幻象)。

幻读对比的是两次当前读返回的结果，@xiaoma20082008 例子里对比的是一次快照读和一次当前读，这个不是幻读的问题。

@lc87624
事务里面有快照读跟当前读，soga
我一直没搞清楚这个问题，刚才看了mvcc搞懂了 多谢，，

MVCC是实现的是快照读，next-key locking 是对当前读 都可以避免幻读

感觉这篇文章讲的不错: http://blog.sina.com.cn/s/blog_499740cb0100ugs7.html
Innodb 要想避免幻读, 需要加锁读.
"如果使用普通的读，会得到一致性的结果，如果使用了加锁的读，就会读到“最新的”“提交”读的结果。"

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
原文

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读。
a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意dml操作），a事务再select出来的结果在MVCC下还和第一次select一样，接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的），a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了，实测在RR级别下确实如此。

如果这样理解的话，Mysql的RR级别确实防不住幻读

在快照读读情况下，mysql通过mvcc来避免幻读。
在当前读读情况下，mysql通过next-key来避免幻读。
select * from t where a=1;属于快照读
select * from t where a=1 lock in share mode;属于当前读

不能把快照读和当前读得到的结果不一样这种情况认为是幻读，这是两种不同的使用。所以我认为mysql的rr级别是解决了幻读的。

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
原文

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读。
a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意dml操作），a事务再select出来的结果在MVCC下还和第一次select一样，接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的），a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了，实测在RR级别下确实如此。

如果这样理解的话，Mysql的RR级别确实防不住幻读

多读出的一行，是因为 "MVCC快照读中，“自己的修改可见”。"还是update的锁把快照读变成了当前读。

同意 @nvidi 的说法。楼上有几个例子中的两次查询根本就不一样的啊。

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
原文

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读。
a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意dml操作），a事务再select出来的结果在MVCC下还和第一次select一样，接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的），a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了，实测在RR级别下确实如此。
如果这样理解的话，Mysql的RR级别确实防不住幻读

多读出的一行，是因为 "MVCC快照读中，“自己的修改可见”。"还是update的锁把快照读变成了当前读。

MVCC快照读本身就包括两部分可见：1、事务开始前已提交的可见 2、自己本事务的修改可见
因此这里应该是本身快照读不可见的记录，由于自己修改过变成了快照读可见

幻读包括count行数这种吗？