非聚簇索引更新易引发死锁，因其需两阶段加锁（先锁二级索引项，再回表锁主键行），且加锁顺序与主键无关；若事务采用不同索引路径或扫描顺序不一致，易形成交叉等待闭环。
INFORMATION_SCHEMA.INNODB_TRX 里查到的死锁链，八成和非聚簇索引（二级索引）有关——它本身不存完整行数据，更新时要先锁二级索引项，再回表查聚簇索引（主键），最后锁主键行。两步加锁 + 顺序不一致，就是死锁温床。
为什么非聚簇索引更新容易引发死锁
非聚簇索引更新不是原子操作：InnoDB 必须先定位并锁定二级索引记录（比如 idx_user_status），再根据其 pk 值去聚簇索引上找对应行、加锁。如果事务 A 和 B 更新同一组数据但走不同索引路径，就可能形成“你等我回表、我等你释放二级索引”的交叉等待。
- 两个事务都用
WHERE status = 'pending'更新，但status字段只有非聚簇索引 → 全量扫描该索引页，锁住多条索引记录（含间隙锁） - 若其中一条记录被另一个事务用主键更新（
UPDATE ... WHERE id = 123），而它又正持有该行的聚簇索引锁 → 死锁闭环形成 -
REPEATABLE READ下，范围查询会触发GAP锁，非聚簇索引上的 gap 锁 + 聚簇索引上的 record 锁，极易交叉
如何确认是二级索引导致的锁扩大
执行 SHOW ENGINE INNODB STATUS，在 LATEST DETECTED DEADLOCK 段里重点看：
- 锁类型是否出现
lock_mode X locks gap before rec或lock_mode X locks rec but not gap—— 前者大概率来自非聚簇索引扫描 - SQL 中
WHERE条件字段是否有索引？用EXPLAIN看key列是否命中二级索引，rows是否远大于实际影响行数 - 对比
INFORMATION_SCHEMA.INNODB_LOCKS中lock_index字段：若值为非主键索引名（如idx_created_at），而非PRIMARY，基本坐实问题源头
优化非聚簇索引更新的三个实操动作
不靠删索引，而是控制它的“锁行为”：
- 给高频更新的二级索引字段补上
INCLUDE（MySQL 8.0.13+）：比如CREATE INDEX idx_status ON orders(status) INCLUDE (id, amount)，让索引覆盖常用更新字段，避免回表 → 减少一次聚簇索引加锁 - 把
WHERE条件改为主键驱动：应用层先查出主键列表（SELECT id FROM orders WHERE status = 'pending' LIMIT 100），再用IN (1,2,3...)批量更新 → 锁直接落在PRIMARY上，顺序可控 - 强制使用主键更新：对单行敏感操作，绕过二级索引，用
SELECT ... FOR UPDATE先按主键加锁，再做业务判断和更新，避免条件扫描带来的不可控锁范围
最容易被忽略的细节：索引顺序与事务一致性
即使加了 INCLUDE 或改用主键，如果多个事务对同一组记录的更新顺序不一致（比如事务 A 按 id ASC 更新，事务 B 按 id DESC），依然会死锁。必须在应用层统一排序逻辑，并确保所有涉及该数据集的写操作都遵循相同物理顺序——这不是数据库能兜底的事，得靠代码约定。
