mysql死锁问题
表：CREATE TABLE `u` (
`id` int(11) NOT NULL,
`name` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
有以下两个情况，第二个情况是name唯一列冲突会产生死锁，而第一种情况是主键冲突不会产生死锁，这是什么 原因呢？不应该都加next-key lock吗？
原表中有哪些数据，也贴一下 yejr 发表于 2022-8-25 14:42
原表中有哪些数据，也贴一下
表里面没有数据的。 yejr 发表于 2022-8-25 14:42
原表中有哪些数据，也贴一下
RR隔离级别 直接分析案例2
session1session2
T0begin;begin;
T1insert into u select 11,22;
持有id=11上的 LOCK_REC_NOT_GAP | X
持有name=22上的LOCK_REC_NOT_GAP | X
T2insert into u select 22,22;
持有id=22上的 LOCK_REC_NOT_GAP | X锁
等待name=22上的 LOCK_ORDINARY | X锁
被阻塞
T3insert into u select 33.10;
请求name=22上的LOCK_INSERT_INTENTION|X，和session2冲突，所以把session2给回滚了
实际上这个死锁是发生在name这个uk上，所以上面这个案例，你可以把id列的值换成其他的，就更好理解些了。
案例1可以参考上面的分析过程，自行解读下。 yejr 发表于 2022-8-25 15:21
直接分析案例2
是的，老师，我不理解的是第一个不会产生死锁的那个情况，(11,22)持有x锁（no gap），（11，33）应该在11主键上会有LOCK_ORDINARY | X锁，当（9，44）插入的时候遇到间隙锁会有插入意向锁产生也会等待，也会产生死锁才对呀，为什么主键上面就没有gap锁了呢？
我理解没错的话LOCK_ORDINARY | X锁 这个就是next key lock吧 yejr 发表于 2022-8-25 15:21
直接分析案例2
叶老师这个死锁 还是发生在 pk 上的
S1 (11,22) 持有id name上的记录锁 ; S2(22,22) 执行的时候这个需要等待name上的记录锁，同时(22,22)获取到 (11到 supremum;之间的gap lock锁)
S1 (33,10) 执行的时候 需要往(11到 supremum之间插入)这个时候 有一个意向插入锁 和 (11到 supremum;之间的gap lock锁)之间冲突 ，
这里锁等待产生环路导致了死锁发生 ；我做了下这个案例是把您说的session1 回滚了
李努力 发表于 2022-8-25 15:43
是的，老师，我不理解的是第一个不会产生死锁的那个情况，(11,22)持有x锁（no gap），（11，33）应该在11 ...
（9，44）和 （11，33） 之间没有锁互斥 主键上面没有gap锁 张旭峰 发表于 2022-8-25 17:13
（9，44）和 （11，33） 之间没有锁互斥 主键上面没有gap锁
为啥主键上没有呢？插入(11,33)的时候，等待应该会产生next key lock吧 张旭峰 发表于 2022-8-25 16:40
叶老师这个死锁 还是发生在 pk 上的
S1 (11,22) 持有id name上的记录锁 ; S2(22,22) 执行的时候这个需 ...
(11到 supremum;之间的gap lock锁) 这里我理解的是name上的（-∞，22]这个next key lock，所以插入(33,10)的时候会死锁了。
页:
[1]
2