按固定顺序访问能减少死锁，因事务统一按主键升序加锁可避免循环等待；需在应用层对id列表排序后再执行update，不可依赖in子句默认顺序。
为什么按固定顺序访问能减少死锁
死锁在高并发 UPDATE 场景下常源于事务以不同顺序加锁：事务 A 先锁 id=5 再锁 id=10，事务 B 反过来先锁 id=10 再锁 id=5，双方等待就卡住。MySQL 的行级锁（尤其是 SELECT ... FOR UPDATE 或 UPDATE）是逐行加锁的，顺序不一致直接放大冲突概率。
固定顺序访问的本质是让所有事务“走同一条路”，把并发竞争从“乱序抢锁”变成“排队等锁”。
如何强制按主键/索引顺序更新多条记录
核心原则：更新前先排序，再拼 SQL 或分批执行。不能依赖应用层随机遍历集合后直接发 UPDATE。
如果用单条
UPDATE ... WHERE id IN (x,y,z)，MySQL 内部加锁顺序取决于执行计划——可能按索引物理顺序、也可能按 WHERE 中值的排序，不可控。必须显式干预。-
正确做法是：在应用层对 ID 列表做升序（或降序）排序，再构造语句
UPDATE users SET status = 1 WHERE id IN (101, 205, 309);
→ 改为UPDATE users SET status = 1 WHERE id IN (101, 205, 309);
（前提是101 ，且 <code>id是主键或有唯一索引） 若需按非主键字段更新（如
UPDATE ... WHERE biz_no = ?），必须确保该字段有唯一索引，否则 MySQL 可能走全表扫描，锁范围不可控；更稳妥的是先查出对应主键，再按主键排序后更新。
批量更新时避免跨段锁升级的陷阱
即使 ID 排了序，若一次更新太多行，MySQL 可能将行锁升级为间隙锁（Gap Lock）甚至临键锁（Next-Key Lock），扩大锁范围，反而增加冲突面。
- 单次
UPDATE涉及行数建议控制在 100 行以内（具体看数据分布和隔离级别） - 分批时仍要保证每批内部 ID 有序，且批次间也保持全局顺序（比如按
id % 4 = 0、id % 4 = 1… 分片，但每个分片内再排序） - 在
REPEATABLE READ隔离级别下，WHERE条件未命中索引会导致全表扫描加锁，务必用EXPLAIN确认执行计划走的是预期索引
应用层实现时容易忽略的细节
- 多线程/协程并发更新同一组记录时，仅靠“ID 排序”不够：如果两个请求都拿到
[5, 1, 3]，各自排序成 [1,3,5] 后发 UPDATE，看似顺序一致，但若中间有其他事务插入了 id=2 或 id=4，间隙锁行为可能让实际加锁路径出现分歧
- 更健壮的做法是：先用
SELECT id FROM t WHERE ... ORDER BY id FOR UPDATE 显式锁定并获取有序 ID 列表，再执行后续逻辑（注意这会阻塞其他事务对该范围的修改，权衡吞吐与确定性）
- 如果业务允许，用
INSERT ... ON DUPLICATE KEY UPDATE 替代条件 UPDATE，可规避部分锁竞争（尤其当冲突主要来自重复写入而非读-改-写流程时）
[5, 1, 3]，各自排序成 [1,3,5] 后发 UPDATE，看似顺序一致，但若中间有其他事务插入了 id=2 或 id=4，间隙锁行为可能让实际加锁路径出现分歧SELECT id FROM t WHERE ... ORDER BY id FOR UPDATE 显式锁定并获取有序 ID 列表，再执行后续逻辑（注意这会阻塞其他事务对该范围的修改，权衡吞吐与确定性）INSERT ... ON DUPLICATE KEY UPDATE 替代条件 UPDATE，可规避部分锁竞争（尤其当冲突主要来自重复写入而非读-改-写流程时）按固定顺序访问不是银弹，它压低的是死锁概率，不是完全消除。真正难处理的是混合访问模式：一部分事务按 ID 更新，另一部分按时间范围（created_at BETWEEN ? AND ?）更新——这时必须统一收敛到同一维度（比如全部转为主键 ID 范围），否则死锁风险依然很高。
