按ID降序更新更容易触发死锁，因为InnoDB加锁顺序默认跟随聚簇索引升序扫描，与应用层传入的降序ID列表错位，导致多事务交叉加锁；真正可控的加锁顺序需应用层先SELECT ... ORDER BY id FOR UPDATE获取升序ID列表，再在同一事务中执行UPDATE。
按ID降序更新为什么更容易触发死锁
因为InnoDB加锁顺序默认跟随索引扫描方向，而批量UPDATE的IN子句本身不保证执行顺序；当应用层传入WHERE id IN (100, 99, 98)这种降序ID列表时，MySQL优化器可能仍按聚簇索引物理顺序（升序）扫描并加锁——结果是“你给的顺序”和“它实际加锁的顺序”错位，多个事务之间极易形成交叉等待。
IN子句里的ID顺序 ≠ 实际加锁顺序
MySQL原生UPDATE语句不支持ORDER BY（8.0.19+仅限极少数单表场景），所以WHERE id IN (…)中ID的排列对InnoDB加锁行为几乎没有影响。真正起决定作用的是：
- 主键是否为自增整型（物理存储连续 → 升序扫描更自然）
- 查询是否命中主键索引（没索引就全表扫，锁范围爆炸）
- 优化器选择的访问路径（比如改用二级索引就会改变锁顺序）
也就是说，你显式写IN (5,4,3,2,1)，InnoDB仍可能先锁1、再锁2……最后锁5——而另一个事务若按常规升序查出ID后拼IN (1,2,3,4,5)，两者表面顺序相反，底层加锁却可能部分重叠、部分错开，死锁概率反升。
降序操作常伴随其他高危习惯
实践中，用降序往往不是为了逻辑需要，而是掩盖了更深层的问题：
- 前端或中间件直接把查询结果倒序后喂给UPDATE，跳过了显式
ORDER BY id的SELECT阶段，导致ID来源不可控 - 主键是UUID或随机字符串时，降序拼IN相当于彻底放弃物理局部性，行锁散落在磁盘各处，间隙锁冲突面扩大
- ORM自动拼接WHERE条件（如MyBatis
<foreach>）未强制排序，传入List顺序依赖JVM或序列化实现，不同节点结果不一致 - 分页场景下用
ORDER BY created_at DESC LIMIT N取ID，但created_at非唯一，导致多次查询结果ID顺序抖动，后续批量更新锁序紊乱
真正可控的加锁顺序只有一种
必须由应用层显式控制：先SELECT id FROM t WHERE ... ORDER BY id拿到升序ID列表，再用这个确定顺序去构造IN或拆成单条UPDATE。注意几个硬性条件：
-
SELECT ... FOR UPDATE和后续UPDATE必须在同一个事务里，中间不能有COMMIT或非锁SQL - ID列表在代码里要显式调用
.sort()（数值排序！别用字符串比'10' - 拼
IN时确认ORM/驱动不会重排参数（例如Spring JDBC默认不重排，但某些连接池或代理层会） - 超过500条建议改用临时表+JOIN，避免
IN过长触发优化器弃用索引
降序本身不是原罪，但它是“没想清楚加锁逻辑”的典型信号——真正要盯住的，永远是那一行SELECT ... ORDER BY id FOR UPDATE有没有被执行，以及它和UPDATE之间有没有被干扰。
