索引下 update 只锁住符合条件的记录吗？

最新推荐文章于 2025-07-15 00:55:55 发布

原创

最新推荐文章于 2025-07-15 00:55:55 发布 · 1k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#MySQL #间隙锁 #next-key lock

在MySQL的RR隔离级别下，UPDATE语句并不只锁定匹配条件的记录，而是会使用next-key lock锁定记录及其间隙。这种行为导致了更新不交集数据时的锁冲突。实验表明，即使索引存在，UPDATE也可能锁住不满足条件的记录，影响并发性能。在高并发写场景下，调整隔离级别如改为RC级别可提升并发能力。

文章目录

起步
环境准备
奇怪的 update 行为
行锁与间隙锁
加锁规则
如何理解“等值查询”和“范围查询”
next-key lock 是两步骤
总结
参考

起步

我着手一个需要高并发 update 的功能，进行压测时，发现了大量锁超时。于是所有矛头就指向我了，认为我做任务分发时重复分发了两个或两个以上相同的子任务。

这一假设基于现有的子任务 update 范围，已知更新语句走索引 c，则有：子任务 A 更新 c=[1,10] ；子任务 B 更新 c=[11,20] … 子任务 N 更新 c=[n-9, n]。所以同事认为，只有可能会出现相同的 A 任务（B、C … N 都行），才可能引发锁超时。

假设同事是正确的，那就意味着 update 只锁主符合条件的记录。但果真如此吗？

环境准备

压测环境隔离级别查看：

show variables like 'transaction_isolation'

得压测环境的隔离为 RR 级别，也就是：REPEATABLE-READ。

准备实验数据，方便研究 update 走索引时的行为：

CREATE TABLE `u` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `c` (`c`)
) ENGINE=InnoDB;

insert into u(id, c) values(null, 1), (null, 2), (null, 3), (null, 4), (null, 5),

最低0.47元/天解锁文章