UPDATE WHERE无索引字段会锁全表，因为InnoDB行锁加在索引记录上；无索引时只能全表扫描，为每条聚簇索引记录加临键锁，实际等效表锁。
UPDATE WHERE 无索引字段为什么会锁全表
InnoDB 的行锁不是加在“数据行”上，而是加在“索引记录”上。当 WHERE 条件无法命中任何索引时，优化器只能走 type = ALL 全表扫描，于是为**每一条被扫描到的聚簇索引记录**都加上记录锁（Record Lock）+ 间隙锁（Gap Lock）。哪怕只有一行匹配，也会锁住所有主键值区间——效果等价于锁整张表。
这不是 bug，是 InnoDB 在无法精确定位时的保守行为：宁可多锁，也不能漏锁，否则会破坏事务隔离性（比如导致幻读或丢失更新）。
- 典型错误现象：
SHOW ENGINE INNODB STATUS里看到大量LOCK WAIT，State: Locked的线程，且Trx has been waiting时间持续增长 -
EXPLAIN FORMAT=JSON显示key字段为NULL、rows值远超预期（如查 10 行却扫 50 万行）、filtered低于 10% - 隐式类型转换也会触发：比如
user_id是INT，但写成WHERE user_id = '123'，MySQL 强制转类型导致索引失效
FORCE INDEX 能绕过锁全表吗
不能。用 FORCE INDEX 或 USE INDEX 只影响执行计划选择，不解决根本问题。
- 如果该索引本身不覆盖
WHERE条件字段（比如对name = 'alice'强制使用idx_created），优化器直接忽略或报错 - 即使有单列索引，对范围条件（如
created_at > '2024-01-01'）也可能因选择性差而扫描大量记录，锁范围依然很大 - 真正起作用的是「索引能否让
WHERE条件精准截断扫描范围」——必须建联合索引，且顺序匹配查询模式。例如WHERE a = 1 AND b > 2，应建INDEX (a, b)，而非(b, a)
如何快速定位正在锁全表的 UPDATE 语句
别靠猜，查真实运行时数据。MySQL 5.7 的 performance_schema 和慢日志组合是最准的入口。
- 先开启诊断开关：
SET GLOBAL slow_query_log = ON，SET GLOBAL long_query_time = 0，SET GLOBAL log_queries_not_using_indexes = ON - 查高影响写操作：
SELECT * FROM performance_schema.events_statements_history WHERE sql_text LIKE '%UPDATE%' AND rows_affected > 1000 - 配合
SELECT * FROM information_schema.INNODB_TRX查看长时间未提交的事务；SELECT * FROM information_schema.INNODB_LOCK_WAITS看谁在等谁
为什么建了索引还是锁得多
索引存在 ≠ 查询能用上 ≠ 锁范围小。关键看是否满足最左前缀、是否被隐式转换、是否覆盖全部过滤条件。
- 联合索引
(status, created_at)对WHERE created_at > '2024-01-01'无效，因为没用上最左列status -
WHERE status IN ('pending', 'processing') AND created_at > '2024-01-01'，即使有(status, created_at)索引，IN 后接多个值可能导致优化器放弃范围扫描，退化为索引全扫描 - 字符集不一致（如列是
utf8mb4，参数传utf8）也会让索引失效，且不易察觉
真正难处理的，往往不是“没建索引”，而是“建了但没用对”——顺序错、类型错、条件写法错，三者任一出问题，InnoDB 就老老实实去扫全表加锁。
