InnoDB锁的是每一条被扫描到的聚簇索引记录，加记录锁+间隙锁；即使只匹配1行，无索引时全表扫描仍等效锁全表，典型表现为EXPLAIN中key为NULL、rows远超预期、filtered低于10。
WHERE条件没走索引时，InnoDB实际锁的是什么
不是“锁了匹配的那几行”，而是为**每一条被扫描到的聚簇索引记录**都加上记录锁 + 间隙锁。哪怕 WHERE name = 'alice' 只命中 1 行，只要 name 没索引，InnoDB 就得全表扫描——于是锁住所有主键值之间的间隙，等效锁全表。
典型信号是：EXPLAIN FORMAT=JSON 里 key 字段为 NULL，rows 值远超预期（比如查 10 条却扫 50 万行），filtered 低于 10。
隐式类型转换也会触发：比如 user_id 是 INT，但写成 WHERE user_id = '123'，MySQL 强制转换导致索引失效。
为什么强制索引（FORCE INDEX）对非索引字段无效
FORCE INDEX (idx_created) 对 WHERE name = 'alice' 完全无效——优化器要么直接报错，要么忽略。因为该索引根本不覆盖 name 字段，强制也没用。
即使有单列索引，对范围条件（如 created_at > '2024-01-01'）也可能因选择性不足导致扫描行数爆炸，锁范围依然很大。
真正起作用的是「索引能否让 WHERE 条件精准截断扫描范围」。所以建索引不是补漏，而是按查询模式反推。
- 例如
WHERE a = 1 AND b > 2，必须建INDEX (a, b)，而非(b, a) - 联合索引顺序必须匹配最常出现的等值+范围组合，
a在前才能用上等值过滤，再用b做范围扫描 - 如果还有
ORDER BY c，且业务允许，可扩展为INDEX (a, b, c)避免额外排序
UPDATE 多表 JOIN 锁死的根源不在语法，在执行路径
MySQL 5.7 的 UPDATE ... JOIN 不是“语法糖”，它会激活嵌套循环连接引擎，进而触发两层加锁：
- 驱动表（JOIN 左侧）满足
WHERE条件的每一行，都加临键锁（next-key lock） - 被驱动表（JOIN 右侧）只要参与匹配，其关联行也加记录锁；若没走索引，直接全表加锁
- 整个过程不提交事务，锁就一直挂着——哪怕 SQL 执行完，锁还卡在 Buffer Pool 里
一旦 ON 或 WHERE 混用多表字段（如 WHERE o.status = 'pending' AND c.country = 'CN'），优化器极易放弃索引，退化为全表扫描 → 全表加锁。
更隐蔽的问题：WHERE 必须写在 SET 后面，且只过滤最终更新集；写在 ON 里的条件不生效于更新逻辑，只影响连接结果——很多人误以为能“提前剪枝”，结果更新了不该动的行。
重构索引后仍锁得紧？检查三个隐藏锁源
别只盯着 WHERE 字段有没有索引。以下三类结构会在你建好联合索引后，依然触发大范围锁：
-
UNIQUE KEY或FOREIGN KEY：它们在READ COMMITTED下仍会隐式加间隙锁用于冲突检测，比如两个事务同时INSERT INTO user (email) VALUES ('a@b.com')，必有一个等待 - 自增主键上的
BULK INSERT（如INSERT ... SELECT）：即使有索引，innodb_autoinc_lock_mode = 1下仍会升为表级 AUTO-INC 锁 - 分区表的 UPDATE：MySQL 先锁所有底层分区表，再判断数据归属；若
WHERE条件无法过滤分区（如没用分区字段），等于锁了全部分区
最易被忽略的是：索引建对了，但查询里用了函数或表达式（如 WHERE DATE(created_at) = '2026-06-01'），直接让索引失效——这种失效不会报错，只会默默退化为全表扫描加锁。
