Innodb:如果发生重复键错误，则会在重复索引记录上设置共享锁。

Question

背景:mysql-refman 5.7

mysql> show create table t1 \G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `i` int(11) NOT NULL,
  PRIMARY KEY (`i`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> select * from t1;
Empty set (0.00 sec)

session1: --------------- operation 1
start transaction;
insert into t1 values(1);

session2: --------------- operation 2
insert into t1 values(1);

session3: --------------- operation 3
start transaction;
insert into t1 values(1);

session1: --------------- operation 4
rollback;

参考文献对上述过程的解释如下：

1. 操作1获取行的排他锁。
2. 操作2,3都会导致重复键错误，并且都请求碎片锁行。
3. 在操作4之后，session1释放该行上的独占锁，会话2，3授予共享锁.

。

Q1:在操作2,3之后，如果未执行操作4，两个会话都在等待行util超时的排他锁。对吗？但是没有像上面第2项那样的“重复键错误”。

​

Q2:为什么在重复键错误发生时，session2和session3请求行的共享锁？这两个会话不应该因为异常而结束吗？

Q3:复制键错误会作为错误信息提示抛出吗？

Q4:为什么重复键错误不结束会话？

​

Answer 1

让我从以下几个方面开始：

Q3:复制键错误会作为错误消息提示抛出吗？

Q4:为什么重复键错误不结束会话？

在不知道哪个客户端发出SQL的情况下，我无法讨论“抛出”和“结束”或“消息提示”。

一般来说，InnoDB的设计考虑到了以下几个方面：

1. ACID --在每一种情况下都得到“正确”的答案，即使从服务器上拔出电源。普通情况下的
2. 速度。

在速度箱里..。

• COMMIT的运行速度比ROLLBACK快。这是一种深思熟虑的选择，基于common.
• Deadlocks被立即确认为更多的COMMIT --即使这意味着有时声称一个可能是avoided.
• Complex的僵局是非常罕见的，以至于他们可能会下注，而不是花费任何额外的努力来解决这个问题。

我认为(不确定)你的3连接冲突是在最后一种情况下发生的。