死锁是多个事务因争夺资源陷入互相等待的僵局，由互斥、持有并等待、不可剥夺、循环等待四条件共同触发；典型场景为两事务以相反顺序更新相同行，导致闭环等待。
SQL数据库死锁本质是多个事务因争夺资源而陷入“互相等待、谁也不让”的僵局。它不是偶然故障，而是并发控制机制（锁）在特定条件下必然出现的现象。只要四个经典条件同时满足——互斥、持有并等待、不可剥夺、循环等待——死锁就可能发生。
死锁是怎么形成的
最典型的场景是两个事务以相反顺序操作相同资源：
- 事务A先更新用户表ID=100的记录（持有了该行排他锁），再试图更新订单表ID=200的记录；
- 事务B几乎同时先更新订单表ID=200（持锁），再试图更新用户表ID=100；
- 此时A卡在等B释放订单行，B卡在等A释放用户行，形成闭环等待。
其他常见诱因包括：间隙锁冲突（如范围查询FOR UPDATE遇上INSERT）、唯一键冲突时的隐式锁、嵌套事务中锁未及时释放、或长事务长时间持有大量行锁。
怎么快速检测死锁
数据库通常自带实时检测能力，无需额外部署工具：
- MySQL：执行 SHOW ENGINE INNODB STATUS\G，重点关注 “LATEST DETECTED DEADLOCK” 部分，能清晰看到哪个事务被选为牺牲者、双方SQL、锁类型及等待关系；
- SQL Server：查询系统视图 sys.dm_tran_locks 和 sys.dm_exec_requests，或启用跟踪标志1222捕获死锁图；也可用SQL Server Profiler监听“Deadlock Graph”事件；
- 通用方法：监控应用层报错日志，死锁异常（如MySQL的 Deadlock found when trying to get lock，SQL Server的 1205 error）是第一手信号。
怎么有效避免死锁
预防比处理更重要，关键在于打破死锁四条件中的至少一个：
- 统一访问顺序：所有业务逻辑对多表/多行操作强制按固定顺序（如“先用户表→再订单表→最后日志表”），从根源上消除循环等待；
- 缩小事务粒度：把一个大事务拆成几个小事务，减少单次持有的锁数量和时间；避免在事务内做HTTP调用、文件读写或人工确认等耗时操作；
- 合理使用索引：确保UPDATE/DELETE语句能走索引，避免全表扫描导致意外升级为表锁或大量行锁；
- 降低隔离级别：在业务允许前提下，用READ COMMITTED替代REPEATABLE READ，减少间隙锁使用；启用快照隔离（如SQL Server的READ_COMMITTED_SNAPSHOT）可基本消除读写阻塞；
- 显式控制锁行为：必要时用SELECT ... FOR UPDATE配合ORDER BY加锁，保证加锁顺序可控；避免在高并发路径上使用SELECT ... LOCK IN SHARE MODE等易引发竞争的操作。
死锁发生后怎么办
数据库通常会自动介入解决：
- 系统自动选择一个事务回滚（称为“牺牲者”），释放其所有锁，使另一方得以继续；
- 应用层必须捕获死锁异常，并实现**幂等重试逻辑**（例如指数退避后重试3次），不能简单抛错给用户；
- 若频繁触发，说明设计存在隐患，需结合死锁日志回溯具体SQL和业务路径，针对性优化访问顺序或拆分逻辑。
