UPDATE语句默认加行级排他锁（X锁）；有索引时精确锁定匹配行，无索引时全表扫描并锁所有扫描行，即使WHERE未命中数据也会锁搜索路径上的间隙。

UPDATE 语句默认加什么锁？

MySQL（InnoDB）中，UPDATE 语句在可重复读（RR）隔离级别下，默认对匹配的行加 排他锁（X 锁），且是**行级锁**；但实际是否真锁住“一行”，取决于有没有可用的索引。

如果没有 WHERE 条件，或 WHERE 条件无法使用索引（如 LIKE '%abc'、字段类型隐式转换、函数包裹列），InnoDB 会退化为全表扫描，并对所有扫描过的记录加 X 锁——此时接近“锁表”效果，极易引发阻塞。

• 有主键或唯一索引：只锁匹配的那几行（精确匹配）
• 有普通索引但非唯一：可能触发 next-key lock（间隙锁 + 行锁），锁住值区间，防止幻读
• 无索引：全表扫描，每条被扫描的记录都加 X 锁，性能差、冲突高

为什么两个 UPDATE 会互相等待甚至死锁？

死锁不是锁太多，而是**加锁顺序不一致**导致的循环等待。比如事务 A 先更新 id=1 再更新 id=2，事务 B 反过来先更新 id=2 再更新 id=1，就可能触发死锁。

InnoDB 检测到死锁后，会主动回滚其中代价较小的事务（通常行锁数量少的那个），抛出错误：Deadlock found when trying to get lock; try restarting transaction。

• 避免方式：所有业务逻辑中，对多行更新严格按相同顺序（如按 id ASC 排序后再更新）
• 不要在应用层分多次 UPDATE 同一批数据；尽量合并为单条语句，或用 SELECT ... FOR UPDATE 预加锁并统一顺序
• 监控死锁：查 SHOW ENGINE INNODB STATUS 中的 LATEST DETECTED DEADLOCK 区域

UPDATE 的 WHERE 条件没命中任何行，还会上锁吗？

会。InnoDB 仍会对 **搜索路径上的索引记录（包括间隙）** 加锁，即使最终没找到数据。这是为了防止幻读，属于 next-key lock 的正常行为。

例如表 t(id PK, name)，当前只有 id=1 和 id=5 两行，执行：

UPDATE t SET name='x' WHERE id = 3;

• 这种“空更新也锁间隙”的行为，在高并发插入场景下容易被忽略，成为隐形瓶颈
• 若确定不需要防幻读（如日志类表），可考虑改用 READ COMMITTED 隔离级别，此时只加行锁，不加间隙锁
• 用 EXPLAIN FORMAT=tree 查看执行计划，确认是否真的走索引、扫描范围多大

如何验证某条 UPDATE 到底锁了哪些行/间隙？

直接查 information_schema.INNODB_TRX 和 INNODB_LOCKS（MySQL 8.0+ 已移除该表）不行——更可靠的是结合 performance_schema.data_locks：

SELECT ENGINE_TRANSACTION_ID AS trx_id,
       OBJECT_SCHEMA,
       OBJECT_NAME,
       INDEX_NAME,
       LOCK_TYPE,
       LOCK_MODE,
       LOCK_DATA
FROM performance_schema.data_locks
WHERE ENGINE_TRANSACTION_ID IN (
  SELECT TRX_ID FROM information_schema.INNODB_TRX
  WHERE TRX_STATE = 'LOCK WAIT' OR TRX_STATE = 'RUNNING'
);

注意：LOCK_DATA 显示的是被锁记录的索引字段值（如主键值）或间隙边界（如 3 表示间隙 (1,3) 或 (3,5)），需结合 LOCK_MODE（如 RECORD、GAP、NEXT-KEY）一起解读。

• 开启前确保 performance_schema 已启用，且 data_locks 表已打开（SET GLOBAL performance_schema = ON;）
• LOCK_MODE = 'X,GAP' 表示只锁间隙，不影响已有记录的更新，但会阻塞插入
• 生产环境慎用长事务 + 大范围 UPDATE，锁持有时间越长，冲突概率越高

实际并发更新中最容易被绕开的问题，是“自以为只改一行，结果因索引失效锁了一整页”，或者“空 WHERE 更新却意外锁住关键间隙”。排查时别只盯 SQL 逻辑，一定先看执行计划和锁视图。