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 就可能趁机插入一条 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 那一行。
哪些情况会让锁“意外扩大”？
锁范围失控往往不是语法问题，而是执行计划偏差导致的：
-
WHERE条件没走索引 → 全表扫描，所有行都可能被加 Record Lock，甚至触发锁升级 - 隐式类型转换（如
WHERE phone = 13800138000，而 phone 是 VARCHAR）→ 索引失效，退化为全表扫描 - 使用函数或表达式（如
WHERE YEAR(create_time) = 2025）→ 无法使用索引，锁范围爆炸 - 事务未及时提交 → 锁长期持有，阻塞面扩大，容易被误判为“死锁”或“慢查询”
怎么验证当前 UPDATE 加了什么锁？
靠 SHOW ENGINE INNODB STATUS\G 查看 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 表面逻辑。
