根本原因是InnoDB行锁加在索引记录上，无索引时被迫全表扫描聚簇索引，并对每行加X锁+间隙锁，效果等同锁表。
不会真正锁“全表”，但效果等同于锁全表——因为InnoDB会对所有被扫描的聚簇索引记录加X锁+间隙锁，而没索引时就得扫完整张表。
UPDATE没走索引时，InnoDB到底锁了什么
锁对象不是“数据行”，而是“聚簇索引记录”。没有主键或可用索引时，InnoDB只能依赖隐藏的row_id（非唯一、不可查、不支持快速定位）作为聚簇索引，导致WHERE条件无法跳过无关行。于是引擎层对每一条被Server层送来的记录都加锁：
-
RECORD LOCK：锁定该行本身 -
GAP LOCK：在可重复读（RR）隔离级别下，顺带锁定前后间隙，防止幻读 -
NEXT-KEY LOCK= RECORD + GAP，是RR下的默认行为
哪怕WHERE city = 'Beijing'最终只匹配10行，只要city没索引，InnoDB就得扫完全部100万行主键记录，并给每条都加next-key锁——锁住的不是“结果集”，而是“扫描路径上的全部索引项”。
EXPLAIN怎么看是否真没走索引
别信语句长得像等值查询，要看执行计划是否实际用了索引。重点盯三个字段：
-
type是ALL或index→ 全表或全索引扫描，危险信号 -
key是NULL→ 没命中任何索引 -
rows接近表总行数（比如表有85万行，rows=824321）→ 实际扫描范围过大
常见假象：WHERE user_id = '123'（user_id是INT）会触发隐式类型转换，key仍为NULL；WHERE DATE(created_at) = '2026-01-01'函数包裹也会让索引失效。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
FORCE INDEX能绕过锁全表吗
不能。强制索引只影响访问路径选择，不改变加锁逻辑：
-
FORCE INDEX (idx_name)对WHERE email = 'a@b.com'且email列根本没建索引 → 优化器直接报错或忽略 - 即使强制了一个存在但不匹配的索引（如用单列
status索引查WHERE status = ? AND created_at > ?），仍因不满足最左前缀而退化为索引全扫描，锁大量无关记录 - 锁多少行，取决于“实际扫描了多少聚簇索引记录”，不是你写了什么
FORCE
真正起作用的是索引能否把扫描范围压缩到业务可接受的程度——例如建联合索引(status, created_at)，才能让WHERE status = 'pending' AND created_at > '2026-09-01'只扫几千行而非百万行。
验证锁范围是否真的降下来了
加完索引别只看执行时间变短，要实测锁行为：
- 开两个会话：会话A执行
UPDATE ... WHERE xxx后不提交；会话B立刻执行相同语句 → 观察是否还阻塞 - 查
INFORMATION_SCHEMA.INNODB_TRX，重点关注TRX_ROWS_LOCKED值：从80万降到500才叫有效 - 在RR隔离级别下，即使有索引，若字段区分度极低（如
status只有3个值），仍可能锁住几十万行——这时得切分逻辑，改用SELECT id FROM ... LIMIT 500再UPDATE ... WHERE id IN ()
最容易被忽略的一点：锁范围收缩 ≠ 并发安全。如果更新涉及外键级联操作，而子表没对应索引，父表一行DELETE仍可能触发子表全扫+全锁——这种链式锁扩散，比单表问题更难排查。
