MYSQL 删除数据是非多，8.030 还是有死锁

来源：这里教程网时间：2026-03-01 17:07:44 作者：

我这个人说问题愿意是感性+理性，首先需要感性认知，我们先来看一个下面的问题，在说这个问题之前，我们先将一些问题说明。

1 数据库版本 8.030 官方版本，社区版本

2 数据库的ISOLATION是 RC

3 数据量不大，就是几条数据进行测试而已

4 这个问题，至少在8.030 以及以下版本都存在这个问题

表一张，数据少许无特殊

create table delete_test (id int not null auto_increment,

name varchar(20),

comment varchar(200),

primary key pk_id (id));

insert into delete_test (name) values ('11');

insert into delete_test (name) values ('22');

insert into delete_test (name) values ('33');

insert into delete_test (name) values ('44');

insert into delete_test (name) values ('55');

下面开始进行找事的操作

Session A

Session B

死锁信息

问题 1，为什么我看上去根本就不搭的两个删除的操作，死锁了，我删除的数据的主键不一样，删除的值不一样，定位的删除记录也不一样，怎么就死锁了？

SESSION 1 delete from delete_test where name = '22' and id < 5;

SESSION 2 delete from delete_test where name = '33' and id < 6;

我们从实际的锁信息中，可以看到第一次的删除的操作的确是锁住 3 ,4 行的数据，而第二次应该去锁定第5行的数据，最终没有，锁定的3行的数据，导致锁的X锁冲突。

问题 2 我将两个操作的顺序颠倒，是否能解决死锁的问题

SESSION 1 delete from delete_test where name = '33' and id < 6;

SESSION 2 delete from delete_test where name = '22' and id < 5;

结果还是一样的，还是死锁了从结果看，我们锁在 5

为什么因为删除会导致锁扩大，我们将操作变化为UPDATE 的操作看看结果如何

答案很明显，同样的语句更换为UPDATE 后，数据将不会在产生死锁，从此我们可以得出一个结论，DELETE 与UPDATE 操作同样的数据，最终的结果是DELETE 会产生死锁，UPDATE 不会。

为什么会这样，我已经使用了RC ，而不是RR，为什么还会导致这样的问题，首先即使是RC ，在每个数据库的操作中都会产生SNAPSHOT，而在这个事务的生命周期中，在进行插入和删除要满足一个条件，就是在一个事务的操作的记录范围内，与另一个事务的操作的范围内，不能有重合，这里不是指的实际的范围，而是你条件的范围。这里MYSQL的设计中的思想是，对所有有可能产生变化的记录全部要加锁，包含不存在的KEY，一般来说如果设计中通过条件来判断操作的范围即可，如我们上面的操作中，一个只要锁3，4 记录即可，另一个只要锁 5好记录即可，但是这使我们人类的想法，而到了数据库中，条件的范围是需要判断的，而且COST 很大，你不知道一个条件的COST 是大是小，所以基于MYSQL的B+TREE 的方式中，无论你DELETE 的操作使用什么隔离级别（RN除外），你都会导致一个key range locking 的锁，保护你操作的区间的记录不被 INSERT 或 DELETE 操作后变化产生的不可预知的数据逻辑错误的问题。

所以我们上面的操作是告知开发一个在使用MYSQL 中重要的问题，不要对数据库进行DELETE操作，这里指的是你的应用程序。应用程序将DELETE 操作更换为，UPDATE 的操作，因为UPDATE 的操作本身并不会引起记录的缺少或增多。这里我们不谈你更新主键的问题，因为从业务或数据库的角度来说，我们都不建议你一个开发去更新主键，这在MYSQL中是一个最大的忌讳。

当然如果想监控到特别详细的锁信息，如果你在show egine innodb status; 中没有发现记录，那么是你下面的这两个部分没有开。

SET GLOBAL innodb_status_output=ON;

SET GLOBAL innodb_status_output_locks=ON;