为什么MySQL中执行UPDATE时匹配不到行仍会产生行锁？-mysql教程-PHP中文网

update没匹配到行仍加锁，因为innodb按索引扫描路径加锁，而非是否命中数据；即使where无结果，也会对扫描涉及的索引项及间隙（如gap lock、next-key lock）加锁，以防止rr级别幻读。

为什么mysql中执行update时匹配不到行仍会产生行锁？

UPDATE没匹配到行，为什么还加锁？

因为InnoDB的加锁行为不取决于“是否找到数据”，而取决于“扫描了哪些索引记录”。哪怕WHERE条件最终没命中任何行，只要优化器决定走某个索引去扫描，InnoDB就会对扫描路径上访问到的所有索引项（包括间隙）加锁。

典型场景是等值查询但值不存在：比如UPDATE users SET status = 1 WHERE name = 'nonexistent_user'，而name字段有普通索引。InnoDB会定位到name索引中该值应处的位置，发现没有对应记录，但仍要锁住这个“不存在的间隙”——这就是Gap Lock。

唯一索引（含主键）等值查询时，若值不存在，只锁间隙，不锁记录
普通索引等值查询时，即使值不存在，也会锁住对应索引项+相邻间隙，且可能触发Next-Key Lock
SELECT ... FOR UPDATE行为一致，不是UPDATE特有

为什么RR隔离级别下必须锁“不存在的行”？

这是为防止幻读设计的底层机制。可重复读（RR）要求事务内多次执行相同查询，结果集必须一致。Gap Lock封锁的是“值的范围”，而非具体记录——它阻止其他事务在该间隙插入新行，从而保证当前事务下次查还能看到同样数量的行。

例如：UPDATE orders SET paid = 1 WHERE order_no = 'ORD9999'，order_no有唯一索引但值不存在。InnoDB会在索引中找到'ORD9999'应插入的位置，并对前后两个边界之间的间隙加锁。此时另一个事务执行INSERT INTO orders (order_no, ...) VALUES ('ORD9999', ...)就会被阻塞。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

RC（读已提交）隔离级别下，这类操作不加Gap Lock，只加Record Lock（但没记录可锁，所以实际不锁）
RR下，即使EXPLAIN显示rows=0，也不能认为“没加锁”
可通过performance_schema.data_locks确认锁类型和范围

如何验证“没匹配到行却加了锁”？

最直接的方式是并发观察：开启事务A执行UPDATE但不提交，再在事务B中尝试插入或更新同一索引范围内的值，看是否被阻塞。配合系统表查锁状态更可靠。

执行以下语句查看当前锁：

SELECT
  ENGINE_TRANSACTION_ID,
  OBJECT_NAME,
  INDEX_NAME,
  LOCK_TYPE,
  LOCK_MODE,
  LOCK_DATA
FROM performance_schema.data_locks
WHERE OBJECT_NAME = 'your_table_name';