MySQL的UPDATE语句不会锁升级，所谓“锁表”实为全表扫描下逐行加记录锁+间隙锁覆盖整个索引范围的结果；WHERE无索引、隐式类型转换、字符集不匹配或大范围更新均会导致等效表锁现象。
MySQL 的 UPDATE 语句不会真正“升级”行锁为表锁——InnoDB 没有锁升级机制。所谓“锁表”，其实是全表扫描 + 逐行加锁 + 间隙锁覆盖整个索引范围的自然结果，等效于表锁，但底层仍是行级锁在起作用。
WHERE 条件没走索引导致全表扫描
这是最常见、最隐蔽的“伪升级”原因。InnoDB 只能对索引记录加锁，一旦 WHERE 字段无索引或索引失效，优化器就会选择全表扫描（EXPLAIN 显示 type=ALL 或 key=NULL），然后对每一条扫描到的聚簇索引记录加 Record Lock，再配合 Gap Lock 封闭所有间隙，在 RR 隔离级别下，最终锁住整个主键索引范围。
- 即使只匹配 1 行（如
UPDATE users SET status=1 WHERE name='alice'），只要name没索引，仍会遍历全部聚簇索引页 - 并发事务执行任意
SELECT ... FOR UPDATE或其他UPDATE，只要涉及同一张表，大概率被阻塞——不是因为真有表锁，而是锁已遍布全表 - 隐式类型转换（如
user_id INT却写WHERE user_id = '123'）或字符集不匹配（列用utf8mb4，常量用utf8）也会让索引失效
大范围更新未分批，锁数量爆炸且持续时间长
即使有索引，单条 UPDATE 影响几万行，也会导致大量行锁长期持有。这不是锁升级，但效果类似：死锁概率飙升、其他事务长时间等待、监控里看到的 “TABLE LOCK” 往往是等待链末端的误判。
DELETE FROM logs WHERE created_at 这类语句直接执行风险极高- 应改用分批：加
LIMIT 1000循环执行，每次COMMIT后释放锁 - 优先按主键范围切片（如
id BETWEEN 1000 AND 1999），避免ORDER BY + LIMIT带来额外排序开销
外键级联操作触发子表全扫
父表执行 DELETE 或 UPDATE 触发 ON DELETE CASCADE 时，若子表关联字段无索引，InnoDB 无法快速定位需删除的子记录，只能全表扫描子表并逐行加锁。
- 例如：
DELETE FROM users WHERE id = 1，而子表orders(user_id)没索引 →orders全扫 - 这和主表
UPDATE本身无关，但整体事务表现就像“锁了整张 orders 表” - 解决方式很简单：确保所有外键列都建有索引
真正容易被忽略的是：RR 隔离级别下，哪怕只锁 1 行，InnoDB 也会自动加上临键锁（Next-Key Lock），覆盖该记录及其前一个间隙——这不是 bug，是为防止幻读的设计。所以“看起来锁得比你写的多”，是常态，不是异常。
