MySQL在执行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 就可能趁机插入一条 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 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 表面逻辑。