MySQL不同索引更新引发死锁的本质是同一表多事务通过不同索引路径修改重叠行导致加锁顺序不一致；根本原因是InnoDB对不同二级索引加锁时先锁二级索引项再回表，路径差异引发循环等待。
MySQL不同索引更新引发的死锁，本质是同一张表上多个事务通过不同索引路径修改重叠行，导致加锁顺序不一致——这不是索引本身的问题，而是InnoDB在不同索引查找路径下加锁行为不可控造成的循环等待。
为什么用不同索引更新同一行会死锁
当两个事务分别走不同索引更新同一行时，InnoDB可能按不同物理顺序加锁：比如事务A用idx_user_id定位到user_id = 100，事务B用idx_phone定位到同一行
phone = '138...'，但内部加锁顺序（如聚簇索引页扫描方向、二级索引遍历路径）可能相反。即使最终锁的是同一行，中间持有的间隙锁或Next-Key Lock范围也可能交叉，形成等待环。</p> <ul> <li>常见错误现象：<code>SHOW ENGINE INNODB STATUS\G中看到两个事务都持有
X locks gap before rec，但等待对方释放不同索引上的锁
user_id主键和phone唯一索引，事务A执行UPDATE user SET status=1 WHERE user_id=123，事务B同时执行UPDATE user SET status=2 WHERE phone='138xxx'
如何强制统一加锁路径
核心思路是让所有更新语句“归一化”到同一个索引路径，避免分支。最可靠的方式是**全部走主键（或一个稳定、高频、覆盖全量的二级索引）**。
- 业务层改写SQL：禁止直接用
WHERE phone = ?或WHERE email = ?更新，改为先查主键SELECT id FROM user WHERE phone = ?，再用UPDATE user SET ... WHERE id = ? - 如果必须单条语句完成，给高频非主键查询字段建联合索引，并确保该索引能覆盖更新所需字段（避免回表），例如
ALTER TABLE user ADD INDEX idx_phone_status (phone, status)，然后用UPDATE user SET status=1 WHERE phone='138...' AND status != 1（注意加上状态过滤减少锁范围） - 禁用隐式索引选择：避免ORM自动生成
WHERE条件顺序不可控的SQL；MyBatis中显式指定useGeneratedKeys="false"并手写WHERE子句；GORM中用Where("phone = ?", phone).Select("id").Find(&u)分步处理
排查时重点看哪些锁信息
光看SQL不够，必须从SHOW ENGINE INNODB STATUS\G的LATEST DETECTED DEADLOCK区块提取真实加锁依据：
- 找
index字段：确认两个事务实际走的是哪个索引（例如index idx_phonevsindex PRIMARY） - 看
lock_mode和lock_type：出现lock_mode X locks gap before rec说明是间隙锁冲突，大概率因范围查询或唯一索引重复插入触发 - 比对
space id和page no：如果两个事务锁在同一个page但不同slot，说明物理位置接近但索引路径分裂 - 检查
undo log entries数量：被回滚事务的undo量小，但若两个事务undo量接近，InnoDB可能随机选一个，此时需更严格约束路径
真正难缠的不是“有没有索引”，而是“同一行被不同索引路径访问时，InnoDB加锁行为不可预测”。线上一旦出现这类死锁，优先砍掉非主键更新入口，而不是调优隔离级别或加锁超时——路径不统一，其他都是治标。
