数据库自动回滚仅限事务内未提交的DML操作，无法撤销外部系统副作用；必须通过幂等、可查的补偿机制（如退款、状态核对）保障最终一致性。
事务提交失败时，数据库会自动回滚未完成的操作，保证数据一致性；但若涉及外部系统（如支付、消息队列、文件存储等），单纯依赖数据库回滚不够，需配合业务层的补偿机制。
数据库自动回滚的前提与限制
当事务中发生异常（如主键冲突、约束违反、连接中断）且未显式提交，数据库会在连接关闭或事务结束时自动执行回滚（ROLLBACK）。但这仅作用于当前数据库内已执行但未 COMMIT 的 DML 操作（INSERT/UPDATE/DELETE）。
- DDL 操作（如 CREATE TABLE）通常隐式提交，无法回滚
- 跨库、跨服务的操作不在数据库事务控制范围内
- 已发出的 HTTP 请求、Kafka 消息、FTP 上传等不会被自动撤销
什么时候必须引入补偿机制？
当一个业务流程包含“数据库操作 + 外部副作用”时，例如：扣减库存 → 调用支付网关 → 发送订单通知。若支付调用成功但后续 DB 提交失败，库存已扣、钱已收，但订单状态未更新——此时需人工或自动补偿。
- 典型场景：分布式事务中的最终一致性保障
- 常见形式：可逆操作（如“退款”抵消“支付”）、状态核对+修复（定时任务比对订单与支付流水）
- 关键要求：每个外部操作需具备幂等性与可查性（如支付单号、消息 traceId）
设计补偿逻辑的实用建议
补偿不是补丁，而是业务流程的一等公民。从开发初期就应明确每一步的正向动作和对应的反向动作。
- 记录完整操作日志：包括入参、返回值、时间戳、上下游标识（如订单ID、支付流水号）
- 使用状态机管理流程：如 order_status ∈ {created, paid, shipped, finished}，每个状态变更对应明确的前置条件与补偿入口
- 异步驱动补偿：通过死信队列或定时扫描异常订单表触发重试或人工介入
- 避免“二次失败”：补偿操作本身也应可重试、有超时、带熔断（如退款失败达3次则告警转人工）
简单示例：电商下单中的补偿链路
用户下单 → 扣库存（DB） → 调支付 → 更新订单状态（DB）
- 若第3步失败：查支付是否成功（调查询接口），成功则触发“生成订单+发通知”补偿；失败则释放库存
- 若第2步超时未返回：主动查支付结果（最多3次），根据结果走不同补偿分支
- 所有补偿动作记入 compensation_log 表，含 status（pending/success/fail）、retry_count、next_retry_at
不复杂但容易忽略：补偿不是兜底，而是把“不可靠的外部依赖”变成“可观察、可追踪、可修复”的确定性环节。
