一  【背景】     今天 上午文能提笔安天下,武能上马定乾坤的 给团队出了一道题目，谁先复现问题，奖励星巴克一杯。激起了一群忙碌的屌丝DBA的极大热情。问题是这样滴，如下图 登博提示了几个细节：    1. code上的uk并未失效。    2. rr隔离级别。    3. 有并发线程的操作。 二 【原理分析】 1 事务隔离级别的基础知识:

•  未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。
•  提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。
•  可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读。
•  串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

 这里重点说一下RR 模式: 可重复读 是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，即使第二个事务对数据进行修改，第一个事务两次读到的的数据是一样的。这样就发生了在一个事务内两次读到的数据是一样的，因此称为是可重复读。

2 MVCC 的读操作

   在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。

当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。

快照读：简单的select操作，属于快照读，不加锁。

select * from table where ?;

当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。

select * from table where ? lock in share mode;

select * from table where ? for update;

insert into table values (…);

update table set ? where ?;

delete from table where ?;

所有以上的语句，都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。

注意:insert操作可能会触发Unique Key的冲突检查，也会进行一个当前读。

  三【解决.复现 】

测试版本: 5.5.18 5.6.16 均可复现。 现在我们根据上述理论信息进行复现问题， 具体的实现步骤如下:

注意 数据库的隔离级别为RR 

session 1	session 2
root@test 08:47:41>set global tx_isolation='REPEATABLE-READ'; Query OK, 0 rows affected (0.00 sec) root@test 08:53:16>set autocommit=0; Query OK, 0 rows affected (0.00 sec) root@test 08:53:22>insert into yy values(1,20,13); Query OK, 1 row affected (0.00 sec) root@test 08:53:31>commit; Query OK, 0 rows affected (0.00 sec) root@test 08:53:39>select * from yy; +----+------+------+ | id | code | val  | +----+------+------+ |  1 |   20 |   13 | +----+------+------+ 1 row in set (0.00 sec)
	root@test 08:53:46>select * from yy; +----+------+------+ | id | code | val  | +----+------+------+ |  1 |   20 |   13 | +----+------+------+ 1 row in set (0.00 sec) root@test 08:53:53>delete from yy where id=1; Query OK, 1 row affected (0.00 sec) root@test 08:53:59>commit;
root@test 08:54:10>insert into yy values(2,20,13); Query OK, 1 row affected (5.59 sec) root@test 08:54:23>select * from yy; +----+------+------+ | id | code | val  | +----+------+------+ |  1 |   20 |   13 | |  2 |   20 |   13 | +----+------+------+ 2 rows in set (0.00 sec)

当session 2中将id=1 的删除之后，session1 进行insert操作时，触发unique key冲突检查，此时因为id=1 code=20 的 数据已经被物理删除了，MySQL 检查无冲突， 进行 insert  insert into yy values(2,20,13); 便成功了。 四【结果展示 】 五【参考资料】  1 《 》  2 《 》