【MySQL】可重复读模式下 unique key失效案例

一 【背景】
   今天上午文能提笔安天下,武能上马定乾坤的登博给团队出了一道题目,谁先复现问题,奖励星巴克一杯。激起了一群忙碌的屌丝DBA的极大热情。问题是这样滴,如下图
【MySQL】可重复读模式下 unique key失效案例
登博提示了几个细节:
   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); 便成功了。
四【结果展示
【MySQL】可重复读模式下 unique key失效案例

上一篇:修复应收账款重复核销问题


下一篇:带你读《C/OS-III内核实现与应用开发实战指南:基于STM32》之三:任务的定义与任务切换