死锁本质是事务以不同顺序锁定同一组行，解决关键是统一加锁物理顺序；UPDATE ORDER BY易失效因执行计划决定加锁顺序，需EXPLAIN验证索引使用；批量更新须应用层控制ID顺序或拆单条；JOIN UPDATE应避免，必要时确保关联字段有唯一索引；游标式更新比LIMIT更可靠；非DB操作必须移出事务。
死锁不是并发高才发生，而是多个事务以不同顺序锁定同一组行——比如事务A先锁id=5再锁id=10，事务B反过来，InnoDB立刻回滚其中一个，报Deadlock found when trying to get lock。解决核心就一条：让所有事务按相同物理顺序加锁，且锁范围可控。
UPDATE ORDER BY id 为什么经常失效？
很多人写UPDATE ... WHERE status = 'pending' ORDER BY id LIMIT 100就以为安全了，但MySQL是否真按id顺序加锁，完全取决于执行计划。若status字段没索引，优化器大概率放弃索引扫描，改走全表扫描 + filesort，结果锁住所有匹配行，顺序彻底失控。
- 必须用
EXPLAIN FORMAT=TRADITIONAL验证：看key是否命中索引、Extra里有没有Using filesort - 复合索引要注意最左前缀：有
(status, id)索引时，WHERE status = ? ORDER BY id才生效；只写WHERE id > 100，该索引基本无效 -
ORDER BY本身不加锁，它只是排序动作；真正决定加锁顺序的是索引扫描路径
怎么确保批量更新按主键顺序加锁？
MySQL原生UPDATE语句不支持稳定排序（8.0.19+仅限极少数单表场景），不能依赖SQL层ORDER BY。必须在应用层控制ID顺序，并确保数据库执行时按此顺序触发行。
- 先执行
SELECT id FROM table WHERE ... ORDER BY id拿到有序ID列表 - 代码中显式
.sort()或sorted()——别信查询结果“看起来有序”，网络传输或驱动可能打乱 - 拼
IN子句时，确保传入顺序与排序后一致；部分ORM（如Django ORM）会重排，需实测验证 - 更稳妥的做法：拆成单条
UPDATE ... WHERE id = ?按序执行（适合几百条以内），或用临时表JOIN更新
为什么多表JOIN UPDATE更容易死锁？
UPDATE t1 JOIN t2 ON ...的加锁顺序由优化器动态决定，和SQL书写顺序无关。事务A可能先锁t2.id=100再锁t1.id=50，事务B却反着来——只要两事务操作的主键有交集，立刻形成循环等待。更麻烦的是，哪怕只更新t1，t2也会被加S锁并持有到事务结束。
- 彻底避免
JOIN更新，改用应用层收拢ID：先查t2要更新的t1.id列表，再分批UPDATE t1 WHERE id IN (...) - 若必须用
JOIN，确保t2的关联字段有唯一索引（防间隙锁），并在ON后加ORDER BY t1.id“暗示”扫描路径 - 检查
EXPLAIN输出：t1必须走主键索引，t2必须走唯一/普通索引，否则直接放弃
游标式更新比LIMIT分页更可靠
LIMIT在UPDATE里不保证幂等分片。比如第一次UPDATE ... ORDER BY id LIMIT 100拿到id 1–100，但中间有其他事务更新了id=50的记录，导致它不再满足WHERE条件，第二次执行就可能跳过它，直接取101–200——业务若依赖严格顺序处理，就会漏数据。
- 改用游标：
UPDATE ... WHERE id > ? AND status = 'pending' ORDER BY id LIMIT 100，每次记录上一批最大id值作为下一批起点 - 避免混合非确定性条件：
WHERE status IN ('a','b') LIMIT 100在并发下实际锁定行集可能每次都不一样 -
LIMIT不是并发控制手段，它只限制影响行数，不解决加锁顺序问题
最容易被忽略的点是：死锁常发生在“看起来很快”的语句上——比如UPDATE只影响3行，但事务里夹着一次HTTP调用或Redis读写，锁持有时间从几毫秒拉长到几百毫秒，这时哪怕加锁顺序完全一致，也容易因等待超时触发Lock wait timeout exceeded。务必把所有非DB操作移出事务块。
