一
【背景】
今天 上午文能提笔安天下,武能上马定乾坤的 登博 给团队出了一道题目，谁先复现问题，奖励星巴克一杯。激起了一群忙碌的屌丝DBA的极大热情。问题是这样滴，如下图
登博提示了几个细节：
1. code上的uk并未失效。
2. rr隔离级别。
3. 有并发线程的操作。
二 【原理分析】
1 事务隔离级别的基础知识:
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 2中将id=1 的删除之后，session1 进行insert操作时，触发unique key冲突检查，此时因为id=1 code=20 的 数据已经被物理删除了，MySQL 检查无冲突， 进行 insert insert into yy values(2,20,13); 便成功了。
四【结果展示 】
今天 上午文能提笔安天下,武能上马定乾坤的 登博 给团队出了一道题目，谁先复现问题，奖励星巴克一杯。激起了一群忙碌的屌丝DBA的极大热情。问题是这样滴，如下图
登博提示了几个细节：
1. code上的uk并未失效。
2. rr隔离级别。
3. 有并发线程的操作。
二 【原理分析】
1 事务隔离级别的基础知识:
- 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。
- 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。
- 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读。
- 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。
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); 便成功了。
四【结果展示 】
