MySQL优化器动态决定JOIN加锁顺序，不受SQL书写顺序影响，易因驱动表选择不一致导致死锁；应拆分为ORDER BY ID的单表查询+升序IN批量更新，并确保索引覆盖和事务边界纯净。
MySQL优化器决定加锁顺序，不是你写的SQL顺序
UPDATE t1 JOIN t2 ON t1.id = t2.t1_id 这类语句，InnoDB 加锁时根本不管你是先写 t1 还是先写 t2。优化器会根据统计信息、索引可用性、表大小等动态选择驱动表——可能事务 A 先锁 t2 再锁 t1，事务 B 却反过来。只要两个事务操作的主键/索引值有重叠（比如都涉及 t1.id = 100 和 t2.id = 200），就极易形成 A 持有 t2.200 等 t1.100、B 持有 t1.100 等 t2.200 的循环等待。
常见错误现象：Deadlock found when trying to get lock; try restarting transaction
- 即使只更新
t1，只要t2出现在ON条件里，InnoDB 就会对t2中扫描到的所有匹配行（甚至间隙）加 S 锁，且这些锁要等到整个事务结束才释放 -
EXPLAIN FORMAT=TRADITIONAL可确认实际驱动表：看table列谁在第一行、type是否为eq_ref或ref，key是否命中索引 - 没索引的关联字段（如
t2.t1_id无索引）会导致t2全表扫描+大量间隙锁，死锁概率陡增
ORDER BY 在 UPDATE JOIN 中基本无效
很多人以为加个 ORDER BY t1.id 就能统一加锁路径，但 MySQL 8.0.19+ 仅对单表 UPDATE ... ORDER BY 保证执行顺序；多表 JOIN 场景下，ORDER BY 被优化器直接忽略——它不参与加锁决策，只影响最终结果集排序（如果有的话）。
真正起作用的是执行计划是否稳定走主键物理顺序。若 t2.t1_id 有唯一索引，ORDER BY t1.id 才可能被当作“访问路径提示”采纳；否则，Extra 字段出现 Using filesort 或 Using temporary 就说明加锁顺序已失控。
- 验证方式：执行
EXPLAIN FORMAT=TRADITIONAL，确认key列显示PRIMARY，且Extra不含Using filesort - ORM 如旧版 MyBatis 自动生成的 JOIN SQL，常因参数绑定顺序不同导致执行计划漂移，加剧锁序分歧
- 别依赖
SELECT ... FOR UPDATE后再UPDATE：中间窗口期可能被其他事务修改，还得重新校验一致性
拆成单表 UPDATE + 升序 ID 列表才是可靠解法
放弃 JOIN，改用应用层分两步：先查出要更新的主键列表，再拼 IN 语句批量更新。关键不是“查出来”，而是查的时候必须 ORDER BY id，且拼接时确保 ID 升序排列——这样每条 UPDATE 都按聚簇索引物理顺序逐行加锁，所有事务路径完全一致。
- 第一步：
SELECT t1.id FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'pending' ORDER BY t1.id（必须带ORDER BY） - 第二步：将返回的 ID 列表按升序分组，每组 ≤ 500 个（避开
max_allowed_packet限制），生成类似UPDATE t1 SET status = 'done' WHERE id IN (1,2,3,...) AND id BETWEEN 1 AND 500 - 若
t2.t1_id无索引，第一步的SELECT本身就会全表扫描+锁大量间隙，得先补索引再上线 - 不要用
LIMIT+OFFSET分页：数据变动时偏移错乱，可能重复锁或跳过行，间接拉长锁持有时间
最容易被忽略的锁持有时间陷阱
死锁常发生在“看起来很快”的语句上。比如 UPDATE accounts JOIN user_logs 只影响 3 行，但事务里夹着一次 HTTP 调用或 Redis 读写，锁持有时间从几毫秒拉长到几百毫秒。这时哪怕加锁顺序完全一致，也容易因等待超时触发 Lock wait timeout exceeded。
- 务必检查事务边界：
BEGIN到COMMIT块内只做 DB 操作，所有非 DB 动作（网络、计算、日志）必须移出 - 跨库场景下，单库加锁顺序完全失效：users 和 orders 若不在同一实例，你锁不住另一个库的行，必须退到应用层协调（如幂等 key + 状态机，或 Redis 分布式锁）
- RR 隔离级别下，未走索引的条件会升级为间隙锁，范围越宽、锁越多、冲突概率越高——索引缺失不是性能问题，是死锁根因
