事务用于把一组读写操作变成清晰的一致性边界。隔离级别越高并不意味着业务越正确，关键是根据并发冲突选择合适的约束、锁策略和重试方式，同时尽量缩短事务持续时间。

核心原则

  • 先定义业务不变量，再决定唯一约束、条件更新或显式锁定方案。
  • 了解当前数据库的默认隔离级别及其快照读、当前读行为。
  • 所有代码路径按一致顺序访问多张表或多行，减少循环等待条件。
  • 事务内只保留必要数据库操作，网络调用和复杂计算放到事务外。
  • 对数据库确认的死锁进行有限重试，并保证操作幂等。

推荐的实践步骤

排查死锁时先获取数据库输出的等待图、涉事 SQL、索引和事务持续时间。判断双方各自持有哪些锁、等待哪些锁，再检查访问顺序和扫描范围。常见修复包括补充选择性索引、统一更新顺序、拆小批次以及缩短事务，而不是简单把超时时间调大。

BEGIN;
SELECT balance
FROM accounts
WHERE id = 1001
FOR UPDATE;

UPDATE accounts
SET balance = balance - 50
WHERE id = 1001;
COMMIT;

示例用于说明实现思路，实际项目还应结合所使用的框架版本、部署环境和业务约束进行调整。重要配置要进入版本管理，并在测试环境验证后再发布。

常见误区

  • 事务中等待外部支付或 HTTP 服务，会长时间持锁并放大阻塞。
  • 没有合适索引的更新可能扫描并锁定大量记录，扩大冲突范围。
  • 对所有数据库错误无条件重试，可能重复业务操作或形成重试风暴。

上线前检查清单

  • 确认“先定义业务不变量，再决定唯一约束、条件更新或显式锁定方案”已经通过代码审查或运行验证。
  • 确认“了解当前数据库的默认隔离级别及其快照读、当前读行为”已经通过代码审查或运行验证。
  • 确认“所有代码路径按一致顺序访问多张表或多行，减少循环等待条件”已经通过代码审查或运行验证。
  • 确认“事务内只保留必要数据库操作，网络调用和复杂计算放到事务外”已经通过代码审查或运行验证。
  • 为失败路径、边界条件和回滚方案准备测试或演练记录。
  • 上线后观察错误率、延迟和资源消耗，确认变化符合预期。

总结

数据库事务、隔离级别与死锁排查指南的关键在于把隐含假设变成可执行的约束，并通过测试、监控和复盘持续验证。先从影响最大的真实场景开始，小步调整并保留回滚能力，通常比一次性大范围改造更安全，也更容易积累可复用的工程经验。