应先通过explain format=json确认insert...on duplicate key update是否命中唯一索引、扫描行数及索引条件使用情况，再结合performance_schema.data_locks实时观察锁类型与间隙范围，避免因索引失效或多个唯一键导致的s→x锁升级死锁。
直接看死锁日志没用，得先确认语句实际加了什么锁。 SHOW ENGINE INNODB STATUS 只告诉你“谁被回滚了”，但不告诉你哪条 INSERT ... ON DUPLICATE KEY UPDATE 触发了锁等待。真正要定位，得在执行前就搞清它到底锁了哪些索引区间。
查执行计划：用 EXPLAIN FORMAT=JSON 看是否走索引
所有 INSERT ... ON DUPLICATE KEY UPDATE 语句，在上线前都该跑一遍 EXPLAIN FORMAT=JSON。重点盯三个字段：
-
key：是否命中唯一索引？若为null，说明没走任何索引，会退化成全表扫描+全间隙锁 -
rows_examined：值越大，锁住的范围越广；线上应控制在个位数或百位内 -
using_index_condition：若为false，说明 WHERE 条件用了函数（如WHERE DATE(create_time) = '2026-09-01'）或OR，极易导致索引失效
看锁类型：RR 下对唯一键冲突会加 NEXT-KEY 锁
在可重复读（REPEATABLE-READ）下，INSERT ... ON DUPLICATE KEY UPDATE 的加锁行为不是原子的，而是分阶段的：
- 先尝试插入 → 加插入意向锁 + 间隙锁（GAP LOCK）
- 发现唯一键冲突 → 对冲突行加 S 型 NEXT-KEY 锁（即记录锁 + 间隙锁）
- 执行 UPDATE → 升级为 X 型 NEXT-KEY 锁
这个“S→X 升级”过程就是死锁温床。尤其当冲突字段是二级唯一索引（非主键）时，InnoDB 无法确定唯一行位置，会锁更大范围，两个事务很容易互相卡在 GAP 阶段。
实时观察锁：用 performance_schema.data_locks（MySQL 8.0+）
MySQL 5.7 用 INFORMATION_SCHEMA.INNODB_LOCKS 已废弃，8.0+ 必须用 performance_schema.data_locks 实时抓锁：
- 执行
SELECT * FROM performance_schema.data_locks WHERE OBJECT_NAME = 'your_table'; - 关注
LOCK_MODE字段：X,REC_NOT_GAP是记录锁，X,GAP是间隙锁，X,NEXT-KEY是最危险的组合 - 比对
LOCK_DATA值，确认是否多个事务在争同一段间隙，比如都卡在(1001, 1003)
注意：data_locks 默认关闭，需提前启用：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';
避免盲目重试：并发写同一唯一键时，锁顺序不可控
这是最容易被忽略的一点：INSERT ... ON DUPLICATE KEY UPDATE 在多个唯一索引存在时，InnoDB 检查索引的顺序取决于建表时索引添加的先后——不是按字母序，也不是按定义顺序，而是物理顺序。这意味着：
- 主库和从库索引顺序不一致 → 主从复制可能出错
- 两个事务同时写
user_id=1001，一个先检查uk_phone，另一个先检查uk_email→ 它们锁定的行不同，后续升级 X 锁时极易形成循环等待 - 没有显式指定唯一键目标，MySQL 自行选择“第一个匹配的唯一索引”，行为不可预测
真正可控的做法，是把冲突字段限定为主键，或确保表只有一处唯一约束；否则，宁可用 SELECT ... FOR UPDATE 显式锁主键再判断，也别依赖 ON DUPLICATE KEY UPDATE 的隐式锁逻辑。
