在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 Locklock_mode X locks gap before rec→ Gap Lock（不可见，但真实存在）lock_mode X后跟table lock→ 表级锁，大概率是没走索引或大范围扫描- 查
INFORMATION_SCHEMA.INNODB_TRX只能看到事务本身，看不到 Gap Lock
真正难调试的从来不是“有没有锁”，而是“锁了哪些索引位置、间隙、以及为什么锁了不该锁的范围”。排查必须结合 EXPLAIN 输出与实际索引结构，而不是只盯着 SQL 表面逻辑。
