根本原因是两个事务以不同顺序更新同一组主键，导致InnoDB加锁路径不一致而形成循环等待；IN子句顺序仅在命中非唯一索引时影响加锁，主键/唯一索引下InnoDB会自动升序重排。
UPDATE 多行时为什么容易死锁
根本原因不是“并发高”，而是两个事务以不同顺序更新同一组主键。比如事务 A 先改 id=5 再改 id=2，事务 B 反过来先改 id=2 再改 id=5，InnoDB 加锁路径不一致，就形成循环等待。InnoDB 行锁的加锁顺序严格依赖索引扫描路径，而扫描路径又由 WHERE 条件、索引类型和语句写法共同决定。
IN 子句里的 ID 顺序真的影响加锁吗
影响，但只在特定条件下生效：UPDATE t SET status=1 WHERE id IN (5,2,3) 这类语句，InnoDB 内部会自动对 IN 列表按主键升序重排后再加锁——前提是命中的是主键或唯一索引。但如果 WHERE 条件走的是非唯一索引（比如普通 INDEX(status)），InnoDB 无法保证扫描顺序，也不会重排 IN 列表，此时应用层不排序就极易出问题。
- 主键/唯一索引：InnoDB 自动排序，
IN顺序可忽略 - 普通索引：InnoDB 不重排，必须在应用层
ORDER BY id后再构造IN列表 - 复合条件如
WHERE user_id=123 AND status='pending'：必须建联合索引，否则可能全表扫描+全表加锁
SELECT FOR UPDATE + 循环 UPDATE 为什么更危险
看似“先锁后更”更可控，实则埋雷更深。因为 SELECT ... FOR UPDATE 的加锁范围取决于它走的索引——如果没走主键，而是走了非唯一索引，就会带上 Gap Lock，锁住整个间隙；后续 UPDATE 又要回主键索引加 X 锁，两步锁顺序和范围都不可控。一旦另一个事务用不同索引路径操作同一行，死锁概率陡增。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 禁止
SELECT FOR UPDATE不带ORDER BY primary_key - 避免在事务中混合使用
SELECT FOR UPDATE和UPDATE，尤其当两者走的索引不一致时 - 若必须分步，确保
SELECT走主键或唯一索引，并显式ORDER BY id
ORM 自动生成 SQL 如何破坏加锁顺序
GORM、MyBatis 等框架拼接 WHERE 条件时，字段顺序不固定。比如两次请求分别生成 WHERE a=1 AND b=2 和 WHERE b=2 AND a=1，即使命中同一联合索引，在某些 MySQL 版本或优化器设置下，也可能触发不同执行路径，导致加锁顺序漂移。这不是 bug，是优化器对等价条件的自由裁量。
- 检查 ORM 日志，确认同一批 ID 的多次更新是否始终生成相同 WHERE 顺序
- 对关键批量更新逻辑，绕过 ORM，手写
UPDATE ... WHERE id IN (...)并确保 ID 排序 - 在联合索引上，强制最左前缀字段出现在 WHERE 中，避免优化器跳过索引
真正难处理的不是“怎么加锁”，而是“怎么让所有事务对同一组数据的加锁路径完全一致”。哪怕只有一处分支逻辑用了不同索引、不同排序、不同拼接方式，就可能在高并发下暴露为周期性死锁。
