死锁源于事务并发时对同一组资源加锁顺序不一致，修复关键在于统一行访问顺序、减少锁持有时间，并确保子查询条件命中索引。
死锁不是SQL写错了，是事务在抢同一组资源
SQL嵌套查询本身不会直接导致死锁，真正触发死锁的是外层事务和内层子查询（尤其是相关子查询或UPDATE/DELETE中的子查询）在并发下对相同行加锁的顺序不一致。典型现象是两个事务各自持有一部分锁，又同时申请对方持有的锁，比如事务A锁了order_id=101，想锁user_id=202；事务B反过来先锁user_id=202，再申请order_id=101。
修复核心不是“重写子查询”，而是让所有事务按**确定顺序访问行**，并尽量减少锁持有时间。
- 用
SELECT ... FOR UPDATE时，务必配合ORDER BY（如ORDER BY id），避免因执行计划差异导致加锁顺序随机 - 嵌套查询若用于
WHERE条件（如IN (SELECT ...)），MySQL 5.7+ 默认可能转成物化临时表，但若子查询没索引，仍会扫描全表并逐行加锁——检查EXPLAIN输出里的type是否为ALL或index - PostgreSQL中
WITH RECURSIVE嵌套若涉及更新，必须确保递归路径唯一且有明确终止条件，否则可能反复尝试锁定同一行
嵌套查询里用FOR UPDATE要特别小心
很多人以为给外层加FOR UPDATE就能控制全部锁，其实子查询里的行可能被单独加锁，且不参与外层事务的锁排序逻辑。尤其当子查询是JOIN或含GROUP BY时，优化器可能提前对中间结果加锁。
实操建议：
- 把嵌套查询拆成两步：先
SELECT id FROM ...拿到主键列表（加ORDER BY id），再用这些id做UPDATE ... WHERE id IN (...)，避免子查询隐式锁表 - 在MySQL中，禁用子查询物化（设
optimizer_switch='materialization=off'）有时反而能强制走索引嵌套循环，减少锁范围 - PostgreSQL中，用
SELECT ... FOR UPDATE OF table_name明确指定只锁某张表，避免子查询关联的其他表也被意外锁定
锁粒度不是越小越好，得看访问模式
有人一听说死锁就立刻加索引、改READ COMMITTED隔离级别，但效果常不好——因为InnoDB的行锁实际是“索引记录锁”，如果查询条件没走索引，照样升级为间隙锁甚至表锁；而PostgreSQL的ROW SHARE锁在高并发下也可能因锁升级冲突。
关键判断点：
- 确认子查询
WHERE条件是否命中索引：用EXPLAIN ANALYZE看Index Cond是否存在，没有就补索引，别只盯着主查询 - MySQL里
UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE ...)，如果t2上没索引，子查询会全表扫描并为每行加临键锁（Next-Key Lock），扩大锁范围 - 不要盲目降级隔离级别：PostgreSQL的
READ COMMITTED对子查询中的SELECT有效，但对外层UPDATE的锁行为影响有限；真要降，得同步评估幻读风险
执行顺序调整比重写SQL更有效
很多死锁源于多个业务模块调用同一组表，但各自按不同字段排序或分页。比如订单服务按created_at查，用户服务按user_id查，两者并发时极易形成环形等待。
解决办法不是让所有人改SQL，而是统一访问契约：
- 所有涉及
orders和users的关联更新，强制按orders.id升序处理（哪怕业务逻辑不需要），用ORDER BY orders.id兜底 - 批量操作拆成固定大小批次（如每次100行），并在批次内排序，避免单次语句锁太多行
- 应用层加分布式锁（如Redis
SET key value NX PX 5000）只锁业务主键前缀（如order:batch:202405），比数据库锁轻量且可控
最常被忽略的一点：嵌套查询的执行计划可能随数据分布变化而漂移，今天不锁，明天数据倾斜就锁。所以必须把锁顺序固化在SQL里，而不是依赖优化器“大概率猜对”。
