分布式事务需外部机制保障一致性，主流模型包括TCC（三阶段拆分）、Saga（反向补偿）和消息队列最终一致性；SQL设计须避免重负载查询、显式指定隔离级别、确保WHERE条件确定性；需全局ID追踪、状态表管理及幂等补偿；慎用XA 2PC，优先选AT模式或轻量级TCC。
分布式事务在 SQL 环境中无法靠单库 ACID 原生保障，必须依赖外部协调机制或应用层补偿逻辑。核心矛盾在于：数据库自身只管本地事务，跨库/跨服务的操作需额外设计一致性保障路径。
理解主流分布式事务模型的适用边界
不同模型解决不同场景，选错会显著增加复杂度和失败率：
- TCC（Try-Confirm-Cancel）：适合业务逻辑可明确拆分为“预留→确认→取消”三阶段的场景，如库存预占、账户冻结。关键在 Try 阶段要幂等且不阻塞核心资源，Confirm 和 Cancel 必须保证最终执行成功（需重试+日志+监控）。
- Saga 模式：适用于长流程、异步化程度高的业务，如订单创建→支付→发券→物流通知。每个步骤对应一个本地事务，失败时按反向顺序执行补偿操作；注意补偿操作本身也要幂等，且需持久化 Saga 执行状态（例如用单独的状态表记录当前步骤）。
- 基于消息队列的最终一致性：常见于微服务间解耦，如 MySQL 更新后发 MQ 消息，下游消费并更新另一库。重点在于本地事务与消息发送的原子性——推荐使用“事务消息表 + 定时扫描”或数据库 binlog + 消息中间件（如 Debezium + Kafka），避免先发消息后写库导致的不一致。
SQL 层面的关键设计约束与规避技巧
即使引入分布式事务框架，SQL 写法仍直接影响成功率和性能：
- 避免跨分片 JOIN 和分布式事务内执行 COUNT(*)、ORDER BY LIMIT 大偏移等重负载查询，这类操作容易触发超时或锁升级，建议提前聚合或改用异步统计。
- 所有参与分布式事务的 SQL 必须显式指定事务隔离级别（通常为 READ COMMITTED），禁止依赖数据库默认值；尤其在 MySQL 中，RR 级别下间隙锁可能引发跨节点死锁。
- UPDATE/DELETE 语句务必带确定性 WHERE 条件（如主键或唯一索引），禁止无条件更新，防止在部分节点执行成功、部分失败时造成数据倾斜或补偿困难。
可观测性与故障恢复不能只靠日志
分布式事务失败往往不是 SQL 报错，而是超时、网络中断或补偿失败，需结构化追踪：
- 每个分布式事务请求生成全局唯一 ID（如雪花 ID），并在所有 SQL 日志、MQ 消息头、服务调用链中透传，便于全链路定位。
- 建立独立的事务状态表，字段至少包含：tx_id、service_name、step、status（pending/confirmed/canceled/failed）、gmt_create、gmt_modified、ext_info（如失败原因、重试次数）。定时任务扫描 status=pending 超时项并触发告警或自动重试。
- 补偿操作不直接复用原业务 SQL，而应封装为幂等函数，入参含 tx_id 和原始业务参数，并在执行前校验前置状态（例如“只有当订单状态为‘已支付’才允许发券”）。
慎用两阶段提交（2PC）及其替代方案
传统 XA 2PC 在高并发、跨异构系统场景下存在明显瓶颈：
- 协调者单点风险高，一旦宕机，所有参与者将长期处于不确定状态（in-doubt），需人工介入。
- Prepare 阶段资源锁定时间长，易引发热点库性能下降，尤其在云环境网络延迟波动时更明显。
- 实际项目中，优先考虑 Seata 的 AT 模式（自动代理 SQL 实现分支事务快照与回滚日志）、ShardingSphere 的柔性事务插件，或基于业务定制的轻量级 TCC 框架，而非直连数据库 XA 接口。
