如何处置MySQL的RR模式下死锁一列
发布时间：2022-01-17 13:21:08 所属栏目：MySql教程 来源：互联网
导读：如何解决MySQL的RR模式下死锁一列，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。 环境：版本5.7.29 RR隔离级别 一、案例模拟 CREATE TABLE `t8` ( `id` bigint(20) NOT NULL AUTO_IN
|
如何解决MySQL的RR模式下死锁一列，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。 环境：版本5.7.29 RR隔离级别 一、案例模拟 CREATE TABLE `t8` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `d_id` varchar(40) NOT NULL DEFAULT '', `b_id` varchar(40) NOT NULL DEFAULT '', `is_dropped` tinyint(1) NOT NULL DEFAULT '0', `u_c` varchar(10) NOT NULL DEFAULT '', PRIMARY KEY (`id`), UNIQUE KEY `DealerAndBrokerAndDropped` (`d_id`,`b_id`,`is_dropped`) ) ENGINE=InnoDB ; insert into t8 values(1,1,1,0,'a'); insert into t8 values(2,2,2,0,'a'); insert into t8 values(3,3,3,0,'a'); insert into t8 values(4,4,4,0,'a'); insert into t8 values(5,5,5,0,'a'); insert into t8 values(6,6,6,0,'a'); insert into t8 values(7,7,7,0,'a'); insert into t8 values(8,8,8,0,'a'); insert into t8 values(9,9,9,0,'a'); insert into t8 values(10,10,10,0,'a'); insert into t8 values(11,11,11,0,'a'); 执行语句如下： |S1|S2| |-|-| |begin|| |select u_c from t8 where d_id=’1’ and b_id=’1’ and is_dropped=0 for update;|| ||select u_c from t8 where d_id=’1’ and b_id=’1’ and is_dropped=0 for update; 处于堵塞状态| |update t8 set u_c=’b’ where d_id=’1’ and b_id=’1’; —此时触发死锁 S2回滚|| 发生死锁记录如下： 如何解决MySQL的RR模式下死锁一列 二、死锁分析 仔细分析我们会发现trx id 5679最后被堵塞需要获取的锁为（lock_mode X waiting），堵塞发生在索引DealerAndBrokerAndDropped 上，也就是这是一个next key lock 且需要获取的模式为LOCK_X，处于等待状态。 而我们来看trx id 5679前面获取的锁是什么呢？显然可以看到为（lock_mode X locks rec but not gap），获取发生在索引DealerAndBrokerAndDropped 上，也就是这是一个key lock且获取模式为LOCK_X。 但是我们需要知道DealerAndBrokerAndDropped明明是一个唯一索引，获取key lock我们很容易理解，但是为什么也会出现获取next key lock呢？这个问题我们先放一下，先来分析一下整个死锁的产生的过程 S1（update操作） 通过索引DealerAndBrokerAndDropped 查找数据（注意这里已经不是唯一性定位操作了，下面会做分析），这个时候首先需要通过查询条件获取出需要更新的第一条数据，实际上这个时候也是d_id=’1’ b_id=’1’ is_dropped=0这条数据，需要获取的锁为LOCK_ORDINARY[next_key_lock]|LOCK_X，这个时候我发现虽然S1之前获取了这条数据的锁，但是锁模式变化了（一致不会重新获取，下面会分析这种行为），因此这里需要重新获取，但是这显然是不行的，因为S2都还处于等待中，因此这里也发生了等待。 因此通过这个过程就出现死锁，S2等S1 S1等S2。 三、关于锁模式的变化 关于这里我们参考函数lock_rec_lock_fast，这里会不进行行锁冲突验证而进行快速加锁，如果锁模式没有变化则也会再这里进行快速加锁（也就是直接跳过），当然如果块中一个row lock 都没有也会在这里进行加锁，这是每个加行锁的操作都必须经历的判断，如果不能快速加锁则进入slow加锁方式，这里看一下下面的这段代码： if (lock_rec_get_next_on_page(lock) || lock->trx != trx || lock->type_mode != (mode | LOCK_REC) || lock_rec_get_n_bits(lock) <= heap_no) { status = LOCK_REC_FAIL; } 这里的lock->trx != trx会判断本次加锁事务和上次加锁事务是否是同一个事务，lock->type_mode != (mode | LOCK_REC)会判断锁模式是否相同。如果不能满足条件则判定为LOCK_REC_FAIL，进入slow加锁方式。 而我们这里S1加锁第一次是LOCK_REC_NOT_GAP|LOCK_X，而第二次是LOCK_ORDINARY[next_key_lock]|LOCK_X，显然变化了，因此进入slow加锁阶段，进行冲突验证，结果嘛也就冲突了。这是本死锁的一个原因。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
