事务失败不能盲目重试，需区分可重试（如死锁、超时）与不可重试错误（如主键冲突），结合事务边界、保存点、补偿机制和幂等设计构建可靠容错体系。
SQL事务失败时，不能只靠“重试”硬扛，关键得看失败原因、事务边界和数据一致性要求。盲目重试可能造成重复扣款、状态错乱或死锁加剧。
区分失败类型：哪些能重试，哪些必须终止
不是所有SQL错误都适合重试：
- 可重试错误：如数据库连接超时、死锁（Deadlock）、临时网络抖动、锁等待超时（Lock wait timeout）。这类问题短暂、外部、非业务逻辑错误，重试1–3次常能成功。
- 不可重试错误：如主键冲突（Duplicate entry）、外键约束失败、数据类型不匹配、空值插入非空字段、语法错误。这些是逻辑或数据问题，重试只会反复失败，需先修正输入或调整业务流程。
在应用层实现带策略的重试（以Java + Spring为例）
避免在SQL语句里写重试逻辑，应在服务层控制：
- 用@Transactional明确事务边界，确保整个业务操作原子性；
- 捕获特定异常（如DeadlockLoserDataAccessException），对死锁自动重试；
- 配合@Retryable（Spring Retry）设置最大重试次数、退避间隔（如指数退避）；
- 记录重试日志（含事务ID、重试次数、SQL摘要），便于排查是否因并发导致高频重试。
数据库侧辅助：用保存点（Savepoint）缩小回滚范围
长事务中部分步骤失败，不必全滚，可用SAVEPOINT精细控制：
BEGIN TRANSACTION; INSERT INTO orders (...) VALUES (...); -- 步骤1 SAVEPOINT order_saved;UPDATE inventory SET stock = stock - 1 WHERE id = 123; -- 步骤2，可能失败 -- 若此处报错，只回滚到 savepoint，保留订单插入 ROLLBACK TO SAVEPOINT order_saved;
-- 后续可补发通知、走补偿流程等 COMMIT;
注意：Savepoint不能跨事务，且不同数据库语法略有差异（MySQL/PostgreSQL支持良好，Oracle需用PL/SQL块）。
终极兜底：事务补偿 + 幂等设计
对无法简单重试的关键操作（如支付、发券），采用“正向执行 + 异步校对 + 补偿”模式：
- 写入业务表同时，落库一条事务快照（含操作类型、参数、状态为“处理中”）；
- 主流程失败后，触发定时任务扫描超时“处理中”记录；
- 通过幂等Key（如order_id + action_type）查最新状态，决定是重试还是发起逆向操作（如退款、回滚库存）；
- 所有对外接口必须校验幂等Token，防止补偿过程引发重复动作。
基本上就这些。重试不是银弹，它只是容错链条中的一环——前面要判错因，中间要控边界，后面要有兜底。设计时多问一句：“如果重试3次还失败，系统还能自愈吗？”
