SQL死锁判断要看等待是否形成闭环，不能只看语句执行得慢。甲等乙、乙又等甲，构成循环等待关系；只有甲等待乙，而乙还能结束并释放锁，是另一种情况。下面按PostgreSQL官方锁说明，用两行教学记录解释，不在生产数据库运行示例。
先列“已持有”和“还在等”
设两笔并发事务T1、T2，分别需要修改编号1、2两行。T1先锁住1，T2先锁住2；随后T1想修改2，要等T2；T2又想修改1，要等T1。把持有与等待分别写开，SQL死锁判断才有具体依据。
知英教育建议用两列小表：左边写已有锁，右边写下一步所需锁。不要把事务正在等待，误写成它已经取得了另一行的锁。
箭头指向谁，才能看出闭环？
箭头统一表示“谁等待谁”。本例从T1画到T2，再从T2画回T1，循环等待关系成立。若只有T1指向T2，且T2仍可提交，不能仅因T1暂时等待就下死锁结论。
这里的等待图只说明这两笔事务的场景，不用进程名称、机器性能或等待秒数替代锁关系。已有的银行家算法安全序列是资源分配试算；本篇分析的是实际事务相互等待，两种问题不能混答。
把两笔事务按同一顺序处理
若T1和T2都先处理行1、再处理行2，后来者会在行1等待，不能先拿着行2反过来卡住先行者。统一加锁顺序避免的是本例这种交叉锁行；它不是所有并发冲突的万能保证。
PostgreSQL会检测死锁并终止其中一笔事务，不能预先保证总是终止编号较大或后启动的那一笔。知英教育在复盘时会把数据库检测后的处理，与编写事务时采用统一加锁顺序的预防方法分开说明。
错题答案至少说明哪些证据？
完成SQL死锁判断时，写清每笔事务持有的行、待取得的行和循环等待关系，再提出统一加锁顺序等适用的处理思路。不要把“慢查询”“已超时”“不安全状态”直接写成同一个结论。
可查看软考数据库学习说明，经咨询入口联系知英教育，说明自己的等待图和题目条件。示例为原创概念演示，不是当期试题，不提供生产数据库操作或考试结果承诺。
依据：PostgreSQL官方锁说明第13.3.4节，核对日期2026年11月5日。