UPDATE未走索引时必然全表扫描，EXPLAIN显示type=ALL、key=NULL、rows接近总行数即为确诊；无索引则InnoDB只能扫描聚簇索引并逐行加X锁与间隙锁，导致大量行被锁定。
UPDATE没走索引，不是“可能”全表扫描，而是必然全表扫描——InnoDB根本没别的路可选。
EXPLAIN UPDATE 看到 type=ALL 就是确诊
MySQL 8.0.19+ 支持直接对 UPDATE 语句用 EXPLAIN，这是唯一靠谱的判断方式：
-
type=ALL：明确表示全表扫描，优化器放弃了所有索引 -
key=NULL：不是没建索引，而是这次查询压根没用上（常见于隐式类型转换、函数包裹、低选择性） -
rows接近表总行数：比如表有 50 万行，rows=482310，说明几乎每行都被扫了一遍
别信“我建了索引”，也别靠感觉。执行 EXPLAIN UPDATE orders SET status = 'shipped' WHERE city = 'Shanghai';，结果说了算。
没索引时，InnoDB 的锁行为就是逐行加 X 锁 + 间隙锁
行锁不是加在“数据行”上，而是加在“索引记录”上。没有索引，就只能扫聚簇索引（即整张表的主键顺序）：
- 每扫描一条聚簇索引记录，就加一个
REC_NOT_GAP记录锁 - 在可重复读（RR）隔离级别下，还会顺带锁住相邻间隙（
GAP），形成NEXT-KEY锁 - 哪怕 WHERE 条件只匹配 1 行，InnoDB 也得把全部主键值都扫完才能确认——所有被扫的主键都被锁了
所以不是“升级为表锁”，而是“锁了所有扫描行”，效果等同于锁表。你在 SHOW ENGINE INNODB STATUS 里看到 trx_rows_locked 接近总行数，就是这个现象。
常见让索引失效却不易察觉的写法
这些写法看着像走了索引，实际仍是 type=ALL：
-
WHERE DATE(created_at) = '2026-09-01'→ 改成WHERE created_at >= '2026-09-01' AND created_at -
WHERE user_id = '123'（user_id是BIGINT）→ 字符串触发隐式转换，索引失效 -
WHERE status = 'pending' OR is_deleted = 1→ 即使两字段都有索引，OR 也可能导致全表扫 - 联合索引
(a, b)，但只写WHERE b = ?→ 不满足最左前缀，索引无效
字符集不一致（比如列是 utf8mb4，但连接参数或常量是 utf8）也会让 key 变成 NULL。
FORCE INDEX 几乎解决不了锁范围问题
强制索引只是告诉优化器“用这个索引”，但它不能改变底层加锁逻辑：
-
UPDATE users FORCE INDEX (idx_city) SET ... WHERE name = 'alice'→ 如果name列根本没索引，FORCE INDEX会报错或被忽略 - 即使强制了一个存在但不匹配查询模式的索引（比如用单列
status索引查WHERE status = ? AND created_at > ?），仍会因无法截断范围而锁大量无关行 - 真正起作用的是索引能否把扫描行数从“几十万”压到“几百”，这取决于是否覆盖查询条件且顺序合理
最易被忽略的一点：索引建了 ≠ 锁少了。锁多少行，取决于实际扫描路径，而不是 WHERE 最终匹配了几行。
