MySQL XA 事务易失败因缺乏高可用协调器，导致PREPARED状态滞留；Seata AT模式需显式加锁防脏写；PostgreSQL dblink不提供真正分布式事务；DTM Saga需幂等补偿防漏。
MySQL XA 事务在分布式场景下为什么经常失败
XA 是 MySQL 原生支持的分布式事务协议，但实际用起来容易卡在 PREPARE 阶段或回滚不干净，根本原因是它依赖两阶段提交（2PC）的协调者可靠性——而 MySQL 自身不提供高可用的事务协调器，一旦 mysqld 挂掉、网络分区或客户端崩溃，XA RECOVER 查出来的 PREPARED 状态就可能长期滞留。
实操建议：
- 只在强一致性不可妥协、且能接受运维复杂度的场景用，比如金融核心账务系统；普通业务优先考虑最终一致性
- 必须定期跑脚本检查
XA RECOVER输出，对残留的FORMATID+GTRID_LENGTH手动执行XA COMMIT或XA ROLLBACK - 应用层要实现幂等重试：XA START 后若超时未收到响应，不能直接重发，得先查
XA RECOVER状态再决定后续动作 - 注意 MySQL 8.0.29+ 对 XA 的
binlog写入顺序做了调整，如果用 Canal 或 DTS 同步，需确认解析逻辑是否兼容XID_EVENT格式
Seata AT 模式怎么避免脏写和脏读
Seata 的 AT 模式靠代理数据源自动解析 SQL、生成前后镜像来实现分支事务回滚，但它默认不加锁，所以并发更新同一行时会出现脏写——后提交的事务覆盖了前一个已提交但尚未全局提交的数据。
实操建议：
- 关键表的更新语句必须带
WHERE条件，且条件字段要有索引，否则 Seata 无法精准定位行，会降级为全表扫描生成镜像，性能崩盘 - 读操作要用
SELECT ... FOR UPDATE显式加锁，或者在业务层加分布式锁（如 Redis 锁），不能依赖 Seata 的“自动隔离” - 避免在同一个全局事务里跨库更新，AT 模式对多数据源的 undo_log 表管理是独立的，跨库回滚失败时难以定位哪一端卡住了
- 注意
undo_log表必须与业务表同库，且字段branch_id类型要和 Seata server 版本匹配（1.4.x 用BIGINT，1.5+ 改成VARCHAR(128)）
PostgreSQL 的 dblink + 事务嵌套为何不等于分布式事务
用 dblink_connect() 在 PostgreSQL 里调远程库，看起来能在一个事务里跑本地 SQL 和远程 SQL，但其实远程操作只是“模拟”在事务中——它本质是建立新连接、单独提交，本地事务回滚时，远程已经提交的数据无法撤回。
实操建议：
-
dblink_exec()返回成功只代表远程 SQL 执行完，不代表它被纳入当前事务上下文；想实现真正的一致性，必须自己实现补偿逻辑（比如记录远程操作日志，失败时调dblink_exec(... 'ROLLBACK')） - 不要在函数里用
dblink_exec()+COMMIT，PostgreSQL 不允许在函数内显式提交，会报错ERROR: cannot commit while a cursor is open - 如果远程库也是 PostgreSQL，可考虑用
postgres_fdw外部数据包装置，配合CREATE SERVER和IMPORT FOREIGN SCHEMA，至少能统一语法，但依然不解决原子性 - 高并发下
dblink连接数容易打满，需在postgresql.conf中调大max_connections，并用连接池（如 pgbouncer）做前置缓冲
Go 用 github.com/yedf/dtm 时如何防止 saga 分支漏补偿
DTM 的 Saga 模式靠正向服务 + 补偿服务配对执行，但开发者常忽略补偿接口的幂等性和失败重试边界，导致部分分支成功、部分补偿失败后状态不一致。
实操建议：
- 每个补偿接口必须校验原事务 ID（
gid）和步骤 ID（trans_type），用数据库唯一索引（如UNIQUE(gid, trans_type, status)）防止重复补偿 - 补偿请求超时时间要设得比正向操作长（比如正向 3s，补偿 10s），因为补偿往往发生在故障恢复期，下游服务可能还没完全拉起
- 不要在补偿逻辑里调第三方 HTTP 接口，DTM 默认最多重试 6 次，每次间隔递增，若第三方不稳定，很容易错过窗口；应把补偿结果落库，再由后台任务异步重推
- DTM client 初始化时务必设置
serverUrl为负载均衡地址（如 Nginx VIP），别直连单个 dtm server，否则该节点宕机后，未完成的 saga 状态就丢失了
分布式事务没有银弹，所有方案都在一致性、可用性、开发成本之间做取舍。最容易被忽略的是：事务边界是否真的覆盖了所有可能出错的环节——比如消息队列投递失败、定时任务漏触发、甚至运维误删了 undo_log 表。这些点不提前对齐，上线后排查起来比改方案还费劲。
