分布式事务复杂在于需兼顾跨节点一致性、可用性与容错性，受网络延迟、节点宕机、时钟不同步等影响，2PC易致悬停事务，需幂等设计；多库异构导致一致性边界模糊；运维排查难度大；实际常可降级为最终一致性。
SQL 分布式事务复杂，核心在于它要同时满足跨节点的一致性、可用性与容错性，而这些目标在分布式环境下天然存在张力。单机事务靠锁+日志就能搞定 ACID，但一拆成多个数据库实例，网络延迟、节点宕机、时钟不同步、部分失败等问题全冒出来了。
跨节点协调成本高
一个事务涉及三个微服务各自连的数据库，就得让它们“步调一致”地提交或回滚。主流方案如两阶段提交（2PC）需要协调者反复跟所有参与者通信：
- 准备阶段：协调者问“你准备好提交了吗？”，每个参与者要加锁、写预提交日志，再回复“OK”或“NO”
- 提交阶段：只有全部回复 OK，协调者才发“正式提交”；只要一个超时或拒绝，就得发“回滚”指令
- 中间若协调者挂了，参与者可能卡在“半提交”状态，需额外机制（如事务日志持久化、超时探测、人工干预）来恢复
网络不可靠直接破坏原子性假设
本地事务默认网络是可靠的，但分布式下一次 RPC 可能超时、丢包、重复。比如参与者明明成功写了日志，却因网络问题没收到协调者的“提交”指令，它就只能等——等不到就变成悬停事务。更麻烦的是，重试可能导致同一条 SQL 被执行两次（如扣款重复），所以还得配合幂等设计、去重表或版本号控制。
数据一致性边界变模糊
不同库可能用不同引擎（MySQL + PostgreSQL + Redis）、不同隔离级别、甚至不同时间戳策略。比如 MySQL 的可重复读依赖 MVCC，而另一个 DB 用的是快照时间戳，两者对“同一时刻看到什么数据”理解不一致。跨库 JOIN 几乎无法做，外键约束失效，约束校验得挪到应用层，还容易漏判。
运维和排查难度指数级上升
单库出问题看 binlog + error log 就行；分布式事务出问题，得串起 N 个服务的日志、协调者的事务表、各参与方的 XA 日志，时间线还可能因网络抖动错乱。一个超时可能源于数据库慢、连接池满、DNS 解析失败，甚至某个中间件悄悄吞了异常。监控上很难定义“事务成功”的统一指标，链路追踪里一个 Span 覆盖多个 DB 操作，但失败原因可能藏在第 3 个节点的磁盘 I/O 里。
不复杂但容易忽略：很多团队不是真需要强一致性分布式事务，而是误把最终一致性场景当成了必须立刻同步的场景。先想清楚“这笔钱晚几秒到账是否真的不可接受”，往往比硬上 Saga 或 TCC 更有效。
