数据库死锁是并发事务处理中最令人头疼的问题之一：两个或多个事务各自持有锁并等待对方释放，导致所有事务都无法推进。作为开发者或 DBA，你可能遇到过应用突然卡死、超时，查看数据库日志才发现死锁错误。本文将通过典型场景，带你一步步定位死锁成因、掌握排查步骤，并给出切实可行的解决策略。
死锁的四个必要条件
要解决死锁，先要理解其产生的条件。死锁的发生必须同时满足四个必要条件：
- 互斥：资源只能被一个事务独占，例如行锁、表锁。
- 持有并等待：事务持有至少一个资源，同时等待获取其他事务持有的资源。
- 不可剥夺：资源只能由持有事务主动释放，不能被其他事务强行剥夺。
- 循环等待：存在一个事务等待环，例如事务A等待B，B等待C，C等待A。
理解这些条件有助于我们在设计阶段预防死锁，后续的排查也会围绕它们展开。
典型场景：两个更新操作互相等待
假设一个电商系统有两个事务：
- 事务T1：更新订单表（order）中订单ID=1的记录，然后更新库存表（stock）中商品ID=100的记录。
- 事务T2：更新库存表（stock）中商品ID=100的记录，然后更新订单表（order）中订单ID=1的记录。
如果T1先锁定了订单行，T2先锁定了库存行，那么T1等待T2释放库存锁，T2等待T1释放订单锁，形成循环等待，死锁发生。这个场景在业务中很常见，尤其是多个服务并发处理关联数据时。
排查步骤：定位死锁
当应用出现超时或报错时，你需要系统性地排查。以下步骤适用于大多数主流数据库（如MySQL、PostgreSQL、SQL Server）。
1. 启用死锁日志并捕获现场
大多数数据库默认会记录死锁信息，但你可能需要显式开启详细日志。例如：
- MySQL：设置
innodb_print_all_deadlocks=ON，死锁信息会输出到错误日志。 - SQL Server：使用
DBCC TRACEON(1222, -1)捕获死锁事件。 - PostgreSQL：通过
log_lock_waits参数记录锁等待。
日志会显示死锁涉及的事务、持有的锁、等待的锁以及SQL语句，这是分析的第一手资料。记得在日志中包含时间戳和会话ID，便于关联其他日志（参考OWASP日志安全速查表，确保日志记录一致且安全）。
2. 分析等待图和锁信息
死锁日志通常会输出等待图（wait-for graph），展示事务之间的循环等待关系。你需要识别：
- 每个事务持有哪些锁（资源、锁类型）。
- 每个事务正在等待哪个锁。
- 涉及的SQL语句和事务隔离级别。
例如，日志可能显示事务T1持有订单表行锁，等待库存表行锁；事务T2持有库存表行锁，等待订单表行锁。这就是典型的循环等待。
3. 重现并验证
根据日志中的SQL，尝试在测试环境重现死锁。可以通过模拟并发事务（如使用多个连接或脚本）来复现，并调整执行顺序确认死锁条件。重现有助于验证根因，并为后续测试解决措施提供依据。
解决步骤：打破循环等待
找到死锁原因后，可以采取以下措施解决：
1. 调整事务访问资源的顺序
统一所有事务对资源的访问顺序，避免循环等待。例如，在上述场景中，约定所有事务都先更新订单表，再更新库存表。这样T2也会先锁订单行，就不会与T1形成等待环。这是最根本的解决方式。
2. 缩小锁范围或降低隔离级别
检查事务是否锁定了不必要的资源。例如：
- 使用索引减少锁定的行数。
- 在允许的情况下，将隔离级别从可重复读降低为读已提交，减少间隙锁（gap lock）的使用。
- 避免在事务中执行耗时操作（如外部API调用），减少锁持有时间。
3. 使用死锁检测与超时机制
数据库通常有死锁检测机制，会选择一个事务作为牺牲品回滚，让其他事务继续。但你需要确保应用能正确处理死锁异常，例如重试被回滚的事务。也可以设置锁等待超时（如 innodb_lock_wait_timeout），但超时可能误杀长事务，需谨慎。
4. 优化索引和查询
全表扫描或不合适的索引会导致锁过多。分析执行计划，为WHERE条件列创建合适的索引，可以减少锁定的行数，降低死锁概率。关于索引设计，可参考《数据库索引原理及常见索引类型详解》。
预防策略：避免死锁的日常实践
除了事后解决，更应在设计和开发阶段预防：
- 保持事务简短：尽量减少事务中的操作数量，快速提交或回滚。
- 避免用户交互：不要在事务中等待用户输入，这会长时间持有锁。
- 使用一致的锁顺序：在代码层面强制要求所有事务按相同顺序获取锁。
- 合理设计索引：确保查询走索引，避免不必要的表锁或间隙锁。
- 监控锁等待：定期检查数据库的锁等待情况，及时调整。
常见误区与失败条件
在排查和解决死锁时，有几个常见误区需要注意：
- 只靠增加超时时间：这并不能消除死锁，只是让问题延迟暴露，可能影响业务。
- 忽略隔离级别：不同隔离级别下锁行为差异很大，例如可重复读下的间隙锁可能引发更多死锁。
- 盲目重试：重试前应分析死锁原因，否则可能死锁依旧，且加重数据库负载。
- 不记录日志：没有详细日志，排查将无从下手。
参考资料
- OWASP 日志安全速查表：关于日志记录的最佳实践，确保死锁日志安全且一致。
- OpenTelemetry Logs 官方文档：了解日志与可观测性集成，帮助关联死锁事件。
延伸阅读