分布式事务不能直接用 BEGIN TRANSACTION，因其仅限单库生效，跨库无协调机制，易致数据不一致；2PC 易因协调者故障卡在 PREPARED 状态，且 SQL 层无法自动修复；真实场景多采用最终一致性与业务补偿替代强一致。
分布式事务为什么不能直接用 BEGIN TRANSACTION
因为 BEGIN TRANSACTION 只在单个数据库实例内生效，跨库时各节点各自开启本地事务，彼此无协调机制。一旦某个库提交成功、另一个库写入失败，就会出现数据不一致——这不是“事务没写好”，而是 SQL 标准本身没定义跨节点的原子性保障。
常见错误现象：COMMIT 后部分库有数据、部分库回滚了但没通知到其他节点；或者某节点崩溃导致事务状态卡在“准备中”无法推进。
- MySQL 默认引擎（InnoDB）不支持跨实例的两阶段提交（2PC）协调者角色
- PostgreSQL 的
postgres_fdw虽能连远程表，但 DML 操作仍只走本地事务，不触发全局一致性协议 - 即使使用
XA START+XID，也需要所有参与方都启用 XA 并由外部事务管理器（如 Atomikos、Seata）统一调度，纯 SQL 命令无法完成
为什么 2PC 在真实场景中容易卡住或丢数据
两阶段提交依赖协调者（Coordinator）全程在线且可靠，而网络分区、协调者宕机、参与者响应超时都会破坏协议完整性。比如第二阶段发送 COMMIT 请求时 coordinator 崩溃，参与者可能永远停留在 PREPARED 状态，既不能提交也不能回滚。
使用场景：银行跨行转账、订单+库存+物流三库更新——看似必须强一致，实则多数业务可接受最终一致，硬上 2PC 反而降低可用性。
- MySQL 的
XA RECOVER能查出悬挂事务，但无法自动修复；需人工介入判断并执行XA COMMIT或XA ROLLBACK - PostgreSQL 的
pg_prepared_xacts视图可查看未决事务，但清理前必须确认其他节点状态，否则可能引发重复提交 - 协调者日志写入失败（如磁盘满），会导致整个事务流程不可逆中断
SQL 层面看不到的底层约束：锁、复制延迟与快照隔离
分布式环境下，每个数据库的 MVCC 快照是独立生成的，SELECT ... FOR UPDATE 只锁本库行，跨库更新时可能读到过期库存或重复扣减。主从复制延迟还会让刚 COMMIT 的数据在从库查不到，进一步干扰应用逻辑。
性能影响明显：为保证一致性常需加全局锁或串行化调度，吞吐量断崖式下降；而放宽隔离级别又会让 READ COMMITTED 在不同库看到不同版本的数据。
- MySQL Group Replication 的
group_replication_consistency设为BEFORE_ON_PRIMARY_FAILOVER可缓解读写不一致，但会增加写入延迟 - PostgreSQL 的
synchronous_commit = on强制等待所有同步备库落盘，但主库故障时可能丢失已确认事务 - 应用层若用
SELECT ... FOR UPDATE再UPDATE，在分库场景下等同于没加锁——锁不住其他库的对应行
替代方案不是不用事务，而是换粒度和时机
真正落地的系统基本不靠 SQL 层解决分布式事务，而是把“事务”拆成可补偿、可重试、带幂等标识的业务动作。比如用消息队列发 order_created 事件，库存服务监听后执行扣减，失败则重试或告警人工介入。
容易被忽略的地方：事务边界往往不在 SQL 语句里，而在服务调用链路中。一个 INSERT INTO orders 成功不代表订单成立，后续的支付回调、通知推送、积分发放任何一个环节失败，都需要独立兜底逻辑，而不是指望数据库回滚全部。
