SQL死锁是多个事务因循环等待对方持有的锁而全部阻塞的状态，本质是并发控制下的正常现象；典型场景包括多表更新顺序不一致、无索引WHERE导致全表扫描、长事务叠加高并发及事务边界不清的嵌套调用。
SQL死锁是多个事务相互等待对方持有的锁，导致所有事务都无法继续执行的状态。它不是数据库故障，而是并发控制下的正常现象，但若频繁发生，会显著影响系统可用性。核心在于“循环等待”——事务A锁了资源1，想获取资源2；事务B锁了资源2，又想获取资源1。
死锁产生的典型场景
常见于以下几种操作组合：
- 多表更新顺序不一致：事务1先更新用户表再更新订单表，事务2反向操作，极易形成锁等待环路。
- 未使用索引的WHERE条件：导致全表扫描并加锁，扩大锁粒度，增加冲突概率。
- 长事务+高并发：事务持有锁时间过长，其他事务排队等待，中间插入新请求后容易卡成闭环。
- 应用层嵌套调用且事务边界不清：如Service A开启事务调用Service B，B又开启新事务或未正确传播事务，造成隐式锁竞争。
数据库如何检测死锁
主流关系型数据库（如MySQL InnoDB、SQL Server、PostgreSQL）均内置死锁检测机制，原理类似：
- InnoDB每秒运行一次死锁检测器，构建“事务-锁等待”有向图，若发现环路即判定为死锁。
- 检测到死锁后，自动选择一个事务作为“牺牲者”（victim），回滚其语句并抛出错误（如MySQL报错 ERROR 1213 (40001): Deadlock found when trying to get lock）。
- 被选为牺牲者的通常是**undo log最小、回滚代价最低**的事务，不一定是最后发起的那个。
实用解决与规避策略
重点不在“避免所有死锁”（不可能也不现实），而在于“降低频率+快速恢复+可定位”：
- 统一DML操作顺序：对涉及多张表的更新/删除，约定固定顺序（如按表名字母序、按业务主次序），让所有事务按同一路径加锁。
- 缩短事务生命周期：只在真正需要原子性的地方开启事务；避免在事务中做HTTP调用、文件读写、复杂计算等耗时操作。
- 合理使用索引和执行计划：确保UPDATE/DELETE语句能走索引，减少行锁升级为间隙锁或表锁；用EXPLAIN验证实际执行路径。
- 应用层重试机制：捕获死锁异常后，延迟几十毫秒再重试（建议指数退避），多数场景下第二次就能成功。
- 监控与分析工具辅助：开启InnoDB状态日志（SHOW ENGINE INNODB STATUS），定期查看LATEST DETECTED DEADLOCK段，定位高频死锁SQL和表。
补充说明：死锁 ≠ 锁等待超时
锁等待超时（Lock wait timeout）是事务等待某个锁超过设定阈值（如innodb_lock_wait_timeout=50秒）后主动放弃，报错 ERROR 1205 (HY000): Lock wait timeout exceeded。这不是死锁，数据库并未介入检测，只是单方面等不及了。两者错误码、触发机制和处理方式都不同，排查时需先区分。
