MySQL UPDATE语句产生排他锁的原因解析

在MySQL InnoDB中，UPDATE语句的锁行为一直是不少开发者踩坑的重灾区。先给一个核心结论：默认情况下，UPDATE加的是行级排他锁（X锁），但具体类型取决于WHERE条件是否命中索引、隔离级别以及有没有匹配记录——命中主键/唯一索引时走Record Lock；范围查询或无索引时是Next-Key Lock（Record Lock+Gap Lock）；查不到记录时只加Gap Lock；没走索引则全表扫描锁所有行。

为啥要这么复杂？因为UPDATE是写操作，InnoDB必须阻止其他事务同时修改或读取同一行数据，否则脏写、覆盖更新、幻读这些一致性问题全来了。排他锁（X锁）就是底层保障。

UPDATE 加的是什么锁？

默认在 InnoDB 中，UPDATE 语句加的是行级排他锁（X锁），但具体锁类型取决于 WHERE 条件是否命中索引、隔离级别、以及是否存在匹配记录：

• WHERE 匹配到存在的主键/唯一索引值 → 加 Record Lock（只锁该行）
• WHERE 是范围条件（如 id > 5）且隔离级别为 REPEATABLE READ → 同时加 Record Lock + Gap Lock（锁住间隙，防插入）
• WHERE 不走索引（全表扫描）→ 实际可能升级为 Table Lock 或大量 Record Lock，性能和阻塞风险陡增
• WHERE 查不到任何记录，但有索引（如 id = 100 不存在，前后索引值是 99 和 101）→ 加 Gap Lock on (99,101)，防止插入

为什么不能只锁“要改的那几行”？

只锁住最终被修改的行，在 REPEATABLE READ 隔离级别下根本防不住幻读。举个例子：事务 A 执行 UPDATE user SET status=1 WHERE age > 25，如果不锁间隙，事务 B 完全可以在 A 扫描期间插入一条 age=30 的新记录——这条记录虽然没被 A 读到，但会被 A 的 UPDATE 顺手改掉，语义瞬间乱套。所以 InnoDB 默认用 Next-Key Lock（Record Lock + Gap Lock）覆盖整个扫描范围。

这也解释了为什么看似简单的单行更新（如 UPDATE t SET v=1 WHERE id=5），在 RR 级别下仍可能阻塞 INSERT INTO t VALUES (6, ...) ——它锁的是索引中 (3,8) 这个间隙，而不是 id=5 那一行。

哪些情况会让锁“意外扩大”？

锁范围失控往往不是 SQL 语法问题，而是执行计划跑偏了：

• WHERE 条件没走索引 → 全表扫描，所有行都可能被加 Record Lock，甚至触发锁升级
• 隐式类型转换（如 WHERE phone = 13800138000，而 phone 是 VARCHAR）→ 索引失效，退化为全表扫描
• 使用函数或表达式（如 WHERE YEAR(create_time) = 2025）→ 无法使用索引，锁范围爆炸
• 事务未及时提交 → 锁长期持有，阻塞面扩大，容易被误判为“死锁”或“慢查询”

怎么验证当前 UPDATE 加了什么锁？

靠 SHOW ENGINE INNODB STATUSG 查看 TRANSACTIONS 和 LOCK WAIT 部分，重点关注：

• lock_mode X locks rec but not gap → 纯 Record Lock
• lock_mode X locks gap before rec → Gap Lock（不可见，但真实存在）
• lock_mode X 后跟 table lock → 表级锁，大概率是没走索引或大范围扫描
• 查 INFORMATION_SCHEMA.INNODB_TRX 只能看到事务本身，看不到 Gap Lock

真正难调试的从来不是“有没有锁”，而是“锁了哪些索引位置、间隙、以及为什么锁了不该锁的范围”。排查必须结合 EXPLAIN 输出与实际索引结构，而不是只盯着 SQL 表面逻辑。