xa事务比本地事务慢得多，因其强制两阶段提交，引入至少两次rpc、tm日志持久化、超时重试等开销，吞吐量仅为本地事务1/5–1/3，p99延迟翻3–8倍。
XA 事务为什么比本地事务慢得多
因为 XA 强制引入网络往返和全局协调开销，不是“加个开关就能用”的平滑升级。单机事务在内存里完成的 commit，XA 至少要走两次 RPC：一次问所有参与者“准备好了吗”，一次再统一发“提交”或“回滚”。中间还夹着事务管理器（TM）持久化日志、等待超时、协调失败重试等环节。
常见错误现象：XA PREPARE 卡住几秒、XA COMMIT 返回超时、MySQL 错误日志里反复出现 ER_XA_RBTIMEOUT 或 ER_XAER_RMFAIL。
- 哪怕所有资源都在同一台机器上（比如 MySQL + Redis 封装成 XA Resource），只要用了 XA 协议，就绕不开两阶段的同步阻塞模型
- MySQL 的
XA START不支持自动 commit，必须显式XA END→XA PREPARE→XA COMMIT，漏掉任一环都会让事务卡在PREPARED状态，长期占用连接和锁 - PostgreSQL 的
pg_xa扩展、Oracle 的DBMS_XA包，底层都依赖 XID 全局唯一性校验，跨服务传错xid字符串格式（比如多空格、非法字符）会导致XAER_INVAL
什么时候真该用 XA，而不是业务层补偿
XA 只在“强一致性不可妥协 + 参与方都支持 XA 协议 + 运维能兜住协调器单点”这三点同时满足时才值得考虑。多数微服务场景下，它反而是故障放大器。
使用场景举例：银行核心系统中，同一笔借贷必须原子写入总账库（Oracle）和明细库（DB2），且监管要求事务级审计追踪，不允许最终一致。
- 不要用 XA 协调 HTTP 服务（如调用下游 REST 接口）——HTTP 本身不提供
prepare能力，强行封装只会让失败路径更难诊断 - MySQL 8.0+ 虽支持
XA，但默认关闭innodb_support_xa（已废弃），实际启用需确认binlog_format=ROW且sync_binlog=1，否则主从不一致风险陡增 - Java 应用用 JTA 时，
UserTransaction的生命周期必须严格绑定线程，线程池复用下容易把 A 请求的 XA 分支混进 B 请求，触发XAER_DUPID
MySQL XA 实操中三个最容易漏的配置点
不是执行了 XA START 就算进了分布式事务——MySQL 侧有三处隐性门槛，缺一不可。
-
max_prepared_statements_count默认是 16，高并发下很快耗尽，报错ER_CANT_DO_THIS_DURING_AN_TRANSACTION；建议调到 512 以上并监控Com_xa_prepare指标 - 必须用
mysql_real_connect()连接时传CLIENT_PROTOCOL_41标志，旧版 C API 或某些 ORM（如早期 MyBatis）未显式开启，会导致XA START被静默忽略 - 执行
XA RECOVER查看待处理分支时，结果集里的formatID、gtrid_length、bqual_length必须和你代码里构造的XID三元组完全一致；MySQL 对大小写和填充字符敏感，HEX('abc')和'616263'在XA COMMIT时会被视为不同事务
性能代价到底有多大：一个可测的参照系
在千兆内网、同机房部署下，纯写入场景中，XA 事务吞吐量通常是本地事务的 1/5 到 1/3，P99 延迟翻 3–8 倍。这不是配置问题，是协议本质决定的。
你可以用这个最小闭环验证：sysbench 跑 oltp_write_only，对比开启 xa=on 和关掉后的 TPS 与延迟分布。注意关掉 binlog 后 XA 不可用，所以真实压测必须带 --mysql-binlog。
- TPS 下降主因不是 CPU，而是网络 RTT 累积——每个 XA 分支至少增加 2×RTT，三节点就是 6×，而本地事务 RTT≈0
- MySQL 的
XA PREPARE会强制刷盘一次 redo log + 一次 binlog（即使sync_binlog=0），这是硬性 I/O 开销，无法绕过 - 别信“异步 XA”方案——所谓异步只是把协调逻辑移到应用层，失败后仍要人工介入清理
PREPARED状态，反而更难追溯
真正难处理的是 PREPARED 状态残留：它不释放行锁、不释放 undo log、不释放连接，只靠 XA RECOVER 手动捞出来 XA ROLLBACK。没人盯的话，可能撑爆 innodb_log_file_size 或填满 tmp_table_size。
