死锁源于事务并发时对同一组资源加锁顺序不一致，修复关键在于统一行访问顺序、减少锁持有时间，并确保子查询条件命中索引。死锁不是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或indexPostgreSQL中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锁在高并发下也可能因锁升级冲突。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能

转载自CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2301_77962241/article/details/161122932