MySQL 5.7中UPDATE WHERE id = ?锁全表，是因为id无索引或隐式转换导致全表扫描，InnoDB被迫对每条聚簇索引记录加记录锁+间隙锁，等效锁全表；FORCE INDEX无效，根本解法是建匹配查询模式的联合索引。
高频点更新（如 UPDATE ... WHERE id = ?）在 MySQL 5.7 中本不该锁表，但一旦变慢或卡住，大概率是行锁升级成了间隙锁或临键锁，根源几乎总是 WHERE 条件没走索引、或索引设计不匹配查询模式。
为什么 UPDATE WHERE id = ? 还会锁全表？
InnoDB 的行锁只加在索引记录上。如果 id 字段没有索引，或者被隐式转换（比如 id 是 INT，但写成 WHERE id = '123'），优化器就会退化为全表扫描——每扫一行，就对对应聚簇索引记录加记录锁 + 间隙锁，最终等效于锁全表。
- 用
EXPLAIN FORMAT=JSON查看执行计划：key字段为NULL、rows值远超预期、filtered低于 10%，基本可断定没走索引 -
SHOW ENGINE INNODB STATUS中若看到大量LOCK WAIT且Trx has been waiting时间持续增长，说明锁已堆积 - 即使只更新一行，只要没索引，InnoDB 就必须“宁可多锁，也不能漏锁”，这是隔离性保障，不是 bug
FORCE INDEX 能解决点更新锁表问题吗？
不能。强制索引只影响执行计划选择，不解决根本问题：如果索引本身不覆盖 WHERE 字段，FORCE INDEX 会被忽略；如果强制的是低效索引（如单列 status 索引用于 WHERE status = ? AND created_at > ?），仍可能因不满足最左前缀而退化为索引全扫描，照样锁大片范围。
-
FORCE INDEX (idx_created)对WHERE name = 'alice'（name无索引）完全无效，优化器直接报错或跳过 - 范围条件（如
created_at > '2024-01-01'）即使有单列索引，也可能因高选择性不足导致扫描行数爆炸，锁范围依然很大 - 真正起作用的是「索引能否让
WHERE条件精准截断扫描范围」——例如WHERE user_id = 123 AND status = 'pending'，应建联合索引(user_id, status)，而非(status, user_id)
如何快速定位正在锁全表的点更新语句？
别靠猜，查真实运行时数据。MySQL 5.7 提供了足够线索，关键是要组合使用：
- 执行
SELECT * FROM information_schema.INNODB_TRX，重点关注TRX_STATE = 'LOCK WAIT'和TRX_MYSQL_THREAD_ID - 用该线程 ID 关联
information_schema.PROCESSLIST，拿到INFO列中的原始 SQL - 再用
EXPLAIN FORMAT=JSON重跑这条 SQL，确认是否真的没走索引 - 若发现是应用层拼接的动态 SQL（如 ORM 自动生成），需回溯代码检查参数类型是否与字段定义一致，避免隐式转换
高频点更新的锁问题，表面看是 SQL 写法或索引缺失，深层其实是查询路径是否能被精确收敛。一个没被覆盖的 WHERE 条件，哪怕只命中一行，也会让 InnoDB 锁住所有它扫描过的索引位置——这点在 5.7 中尤其明显，因为它的锁管理还没像 8.0 那样做更细粒度的预分配和解耦。
