根本原因是innodb行锁只能加在索引记录上；无索引时需全表扫描聚簇索引，对每条扫描记录加x锁+间隙锁，等效锁表。

更新无索引列会锁死整张表，根本原因不是 MySQL “要锁表”，而是 InnoDB 行锁只能加在索引记录上；没索引，就只能扫聚簇索引（即整张表），并对每条扫描到的记录加 X 锁 + 间隙锁——效果等同于锁表。

为什么没索引就等于锁全表

InnoDB 的行锁对象是「索引记录」，不是“数据行”。当 WHERE 字段没索引时，优化器被迫走 type = ALL 全表扫描，引擎层就得逐条判断并加锁：

• 每扫描到一条聚簇索引记录（也就是主键行），就加一个记录锁（REC_NOT_GAP）
• 在可重复读（RR）隔离级别下，还会顺带把相邻间隙也锁住（GAP）
• 哪怕最终只有一行匹配，所有被扫描的主键值及其间隙都会被锁死

所以不是“锁升级”，而是“锁得太多”——扫描多少行，就锁多少行+间隙。

怎么一眼看出 UPDATE 正在锁全表

别靠猜，直接用 EXPLAIN 看执行计划，盯这三个字段：

• type 是 ALL 或 index → 全表或全索引扫描，基本没走有效索引
• key 显示 NULL → 没命中任何索引
• rows 接近表总行数（比如表有 80 万行，rows 显示 79 万）→ 实际扫描范围失控

典型失效场景：WHERE DATE(created_at) = '2026-09-01'、WHERE user_id = '123'（user_id 是 INT）、WHERE status = ? 但 status 列没有索引。

建什么索引才真正管用

不是“加个索引”就行，得匹配查询模式。高频更新的 WHERE 条件必须覆盖，且顺序不能错：

• 单列等值条件 → 直接建单列索引：ALTER TABLE orders ADD INDEX idx_status (status)
• 多列组合条件（如 WHERE status = ? AND created_at > ?）→ 必须建联合索引，且顺序为“等值在前、范围在后”：ALTER TABLE orders ADD INDEX idx_status_created (status, created_at)
• 别建反了：(created_at, status) 对 status = ? AND created_at > ? 基本无效

如果 status 值分布极不均匀（比如 95% 都是 'pending'），即使有索引，也会锁住几十万行——此时应考虑先查 ID 列表再分批更新。

强制索引（FORCE INDEX）有用吗

多数情况下没用。因为 FORCE INDEX 只影响访问路径选择，不改变锁行为本质：

• 如果强制的索引本身不适合该查询（比如单列 idx_created_at 用于 WHERE status = ? AND created_at > ?），优化器仍可能拒绝使用
• 更关键的是，FORCE INDEX 对全表扫描场景下的加锁范围毫无约束力——扫多少行，就锁多少行+间隙
• 验证是否真用了索引，得看 EXPLAIN FORMAT=JSON 中的 used_key 和 key_length

真正有效的解法是建覆盖查询模式的联合索引，而不是依赖提示。

最容易被忽略的一点：锁本身是行级的，但事务不提交，锁就一直挂着。别人想改同一行就得排队，人一多，看起来就像“表被锁死”。这不是锁升级，是锁被占着不放。