InnoDB范围更新非聚簇索引时必须回表加锁，即先锁二级索引记录，再根据主键值逐条锁定聚簇索引行，并加Next-Key Lock；非唯一索引+范围条件会导致聚簇索引大面积锁定，且无法跳过聚簇索引加锁。
范围更新非聚簇索引时，InnoDB必须回表加锁
MySQL对非聚簇索引（即二级索引）执行范围更新（如 WHERE status BETWEEN 1 AND 3）时，InnoDB不会只锁二级索引项——它必须先锁住匹配的二级索引记录，再根据其中存储的主键值，去聚簇索引（主键B+树）上定位并锁定对应的数据行。这个“先二级、后聚簇”的两阶段加锁不是原子操作，中间存在时间窗口。
常见错误现象：SHOW ENGINE INNODB STATUS\G 中看到事务同时持有 RECORD LOCKS 在二级索引和聚簇索引上，且 WAITING FOR THIS LOCK TO BE GRANTED 指向另一层索引。
- 即使 WHERE 条件只涉及一个普通索引字段，只要它是范围查询（
>、<、BETWEEN、LIKE 'abc%'），InnoDB 就会走该索引的范围扫描路径，逐条回表 - 回表过程不是批量完成的：引擎层每从二级索引取出一条主键值，就立刻去聚簇索引加 X 锁；若此时另一事务已锁住某主键行，当前事务就会卡在那一步
- RR 隔离级别下，该过程还会叠加 Next-Key Lock：不仅锁住命中的主键行，还锁住这些主键值之间的间隙，进一步扩大聚簇索引上的锁范围
非唯一二级索引 + 范围条件 = 聚簇索引大面积锁定
当二级索引是非唯一的（比如 KEY idx_status (status)），且更新语句使用范围条件时，InnoDB 无法预判有多少主键会被影响，只能保守地按索引顺序逐个处理。这导致聚簇索引上被锁的行往往远超业务预期。
使用场景举例：一张订单表有 status 普通索引，执行 UPDATE orders SET updated_at = NOW() WHERE status IN (0, 1)。即使只有 20 行 status=0 和 15 行 status=1，InnoDB 可能因索引页内数据分布，在 idx_status 上扫描到更多叶子节点，并对对应的所有主键行加锁——包括那些尚未提交、正在被其他事务修改的行。
- EXPLAIN 显示
type: range且key: idx_status，不代表只锁 35 行；要看rows估算值和实际performance_schema.data_locks输出 - 若
status值高度重复（比如 90% 订单都是 status=0），该索引选择性差，优化器可能仍选它，但锁代价极高 - NULL 值会被统一归入一个隐式间隙段，所有
status IS NULL的行及它们之间的间隙也会被纳入锁范围
为什么不能只锁二级索引，跳过聚簇索引？
因为二级索引不存完整行数据，只存索引列值 + 主键值。UPDATE 要改的是真实数据行（比如 updated_at 字段），而该字段只存在于聚簇索引的叶子页中。InnoDB 必须通过主键找到那条记录，才能执行修改并加锁——这是存储结构决定的硬约束，不是配置或版本能绕过的。
强制使用 FORCE INDEX 或改写 SQL 无济于事：如果目标字段不在二级索引中，就无法避免回表；如果用了覆盖索引（如 KEY idx_status_u (status, updated_at)），那也只是让 SELECT 不用回表，UPDATE 依然要改聚簇索引里的数据，照样得锁主键行。
- 唯一索引（含主键）可直接定位到聚簇索引页，因此等值更新通常只锁一处；但范围更新仍需扫描多条主键记录，锁范围由扫描路径决定
- 联合索引能否减少聚簇索引锁？仅当 UPDATE 的 SET 子句字段全部被覆盖，且 WHERE 条件能精确截断扫描（如
WHERE a = 1 AND b > 10走INDEX (a, b)），才可能缩小扫描行数，从而间接减少聚簇索引加锁量 - 真正降低聚簇索引锁压力的方式，是把高频范围更新迁移到主键或唯一索引路径上，例如用
id IN (SELECT id FROM ...)先获取主键集合，再用主键批量更新
容易被忽略的关键点
很多人盯着二级索引有没有建、有没有命中，却忘了 InnoDB 加锁的终点永远是聚簇索引——哪怕你只写 UPDATE t SET x = 1 WHERE non_pk_col = ?，最终阻塞别人的，也是你在主键上持有的那些 X 锁和间隙锁。排查死锁时，performance_schema.data_locks 里显示的 LOCK_TRX_ID 和 LOCK_DATA（尤其是后者显示主键值）比二级索引名更能说明问题。
