至于RR隔离级别下到底会不会出现幻读，就需要看幻读的定义中的查询到底是连续的查询还是不连续的查询。如果认为RR级别下可能会出现幻读，那该级别下也会出现不重复读。
RR隔离级别下，虽然不会出现幻读，但是会因此产生其他的问题。
前提：当前数据表中只存在(1,1),(5,5),(10,10)三组数据。
如果数据库隔离级别不是默认，可以执行SET SESSION tx_isolation='REPEATABLE-READ';(该语句不是全局设置)更新为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) 开启事务一，并查询code>8的记录，只有一条(10,10)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test values(11,11);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec) 开启第二个事务，插入(11,11)并提交
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec) 事务一再查询一次，由于RR级别并没有读到更新
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test values(11,11);
ERROR 1062 (23000): Duplicate entry '11' for key 'PRIMARY' 事务一明明没有查到，却插入不了
4.5 更新丢失(Lost Update) 4.5.1 更新丢失
除了上述这类问题外，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) 开启事务一，并查询code>8的记录，只有一条(10,10)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update test set id=12,code=12 where id=10;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.00 sec) 开启第二个事务，将(10,10)改为(12,12)并提交，注意这里matched是1，changed也是1
mysql> select * from test where code > 8;
+----+------+
| id | code |
+----+------+
| 10 | 10 |
+----+------+
1 row in set (0.01 sec) 事务一再次查询code>8的记录，仍然只有一条(10,10)
mysql> update test set id=9,code=9 where id=10;
Query OK, 0 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0 这里查询到0条，更新了0条
这个例子里，事务一的更新是无效的，尽管在这个事务里程序认为还存在(10,10)记录。
事务一中更新之前的SELECT操作是快照读，所以读到了快照里的(10,10)，而UPDATE中的WHERE子句是当前读，取得是最新版本的数据，所以matched: 0 Changed: 0。
如果上述例子中的操作是对同一条记录做修改，就会引起更新丢失。例如，事务一和二同时开启，事务一先执行update test set code=100 where id=10;，事务二再执行update test set code=200 where id=10;，事务一的更新就会被覆盖。
这就是经典的丢失更新问题，英文叫Lost Update，又叫提交覆盖，因为是最后执行更新的事务提交导致的覆盖。还有一种更新丢失叫做回滚覆盖，即一个事务的回滚把另一个事务提交的数据给回滚覆盖了，但是目前市面上所有的数据库都不支持这种stupid的操作，因此不再详述。
4.5.2 乐观锁与悲观锁这种情况下，引入我们常见的两种方式来解决该问题
乐观锁：在UPDATE的WHERE子句中加入版本号信息来确定修改是否生效