mysql为什么会产生行锁升级表锁_锁粒度控制与索引扫描范围-mysql教程-PHP中文网

update没走索引会锁全表，因innodb行锁加在索引上，无索引时退化为聚簇索引全扫描并加x锁，rr级别下还触发gap lock和next-key lock，逻辑上锁整表。

mysql为什么会产生行锁升级表锁_锁粒度控制与索引扫描范围

为什么 UPDATE 没走索引会锁全表

MySQL InnoDB 的行锁本质是加在索引上的，不是加在数据行上。当 UPDATE 或 DELETE 语句的 WHERE 条件无法命中任何索引（比如字段没建索引、用了函数、类型隐式转换、或 OR 导致索引失效），InnoDB 就无法精确定位目标行，只能退化为聚簇索引全扫描 —— 也就是遍历所有主键记录，并对每一条都加 X 锁。

在默认的可重复读（RR）隔离级别下，这种全扫描还会触发间隙锁（Gap Lock）和临键锁（Next-Key Lock），把所有扫描过的索引间隙也锁住，结果就是逻辑上“锁了整张表”。这不是 MySQL 主动升级，而是锁机制在无索引场景下的自然表现。

典型错误写法：UPDATE users SET status = 1 WHERE SUBSTRING(phone, 1, 3) = '138'（函数导致索引失效）
常见隐式转换：WHERE user_id = '123'（user_id 是 INT，传字符串会放弃索引）
排查方法：执行 EXPLAIN 看 type 是否为 ALL，key 是否为 NULL

gap lock 和 next-key lock 如何扩大锁范围

RR 隔离级别下，InnoDB 用临键锁（Next-Key Lock = Record Lock + Gap Lock）防止幻读。这意味着哪怕你只更新一行，只要 WHERE 条件涉及范围（如 BETWEEN、>=、LIKE 'abc%'），它就可能锁住“值本身 + 后面的间隙”，甚至跨行锁定。

例如：UPDATE orders SET paid = 1 WHERE created_at > '2026-04-01'，若 created_at 有索引但无唯一性，InnoDB 会锁定所有满足条件的记录，以及这些记录之间的间隙 —— 如果索引页里存在多个时间点，实际锁住的可能是几十甚至上百行，远超你的预期。

MySQL

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

下载

关键点：SELECT ... FOR UPDATE 或写操作在 RR 下都会触发临键锁，RC 下则只锁匹配行，不锁间隙
验证方式：查 information_schema.INNODB_TRX 和 INNODB_LOCKS（MySQL 5.7+ 已移除，改用 performance_schema.data_locks）
影响：锁范围越大，事务等待越久，死锁概率越高

唯一索引 vs 普通索引对锁粒度的影响

同样是等值查询，唯一索引（含主键）和普通索引的锁行为完全不同。唯一索引能精确锚定单行，InnoDB 只加 Record Lock；而普通索引即使查到唯一值，也可能先锁二级索引项，再通过主键回表，过程中若涉及范围扫描或未提交事务，就可能多锁几行。

更隐蔽的是：如果 WHERE 条件用了普通索引字段，但该字段允许 NULL，InnoDB 在 RR 下会把所有 NULL 值所在间隙也纳入 Gap Lock 范围 —— 这些间隙往往被忽略，却是并发冲突高发区。

示例：UPDATE users SET name = 'a' WHERE email = 'x@y.z'，若 email 是普通索引且有大量 NULL，可能意外锁住一堆空值间隙
优化建议：高频等值更新字段尽量建唯一索引；非唯一字段更新时，确认是否真需要 RR 隔离级别
注意：INSERT ... ON DUPLICATE KEY UPDATE 在唯一冲突时会加 insert intention lock，也可能与 gap lock 冲突

如何快速判断当前 SQL 锁了哪些行/间隙

不能只看 SQL 表面逻辑，得结合执行计划、索引结构、事务隔离级别三者交叉验证。最直接的方式是复现问题后立刻查 performance_schema.data_locks（MySQL 8.0+）或 INNODB_ENGINE_STATUS 输出（5.7）。

例如执行 SELECT * FROM performance_schema.data_locks WHERE LOCK_TRX_ID = 'xxx';，返回中 LOCK_MODE 为 X,REC_NOT_GAP 是纯行锁，X,GAP 是间隙锁，X,NEXT-KEY 是临键锁 —— 后两者才是真正容易引发阻塞的“隐形范围锁”。