MySQL XA事务不能保证强一致性，它仅提供两阶段提交协议框架，实际一致性依赖节点合规性、网络可靠性及崩溃恢复能力，且不解决单点故障、脑裂等问题。
MySQL XA事务能保证强一致性吗？
不能直接保证，它只提供两阶段提交（2PC）的协议框架，真正的一致性取决于所有参与节点是否都严格遵循协议、网络是否可靠、宕机后能否正确恢复。XA本身不解决单点故障、不自动重试、也不处理脑裂——这些得靠上层协调器或应用兜底。
常见错误现象：XA COMMIT 执行一半失败，导致部分节点已提交、部分还在PREPARED状态；XA RECOVER 查不到某些PREPARED事务，因为binlog没刷盘或crash发生在prepare之后、commit之前。
- 使用场景：跨库更新（如订单库+库存库）、需要ACID保障的金融类写操作
- 必须开启
innodb_support_xa=ON（MySQL 8.0.30+默认ON，但老版本需显式配置） -
XA START后的语句不能包含DDL、临时表、非事务引擎操作，否则会隐式commit并报错XAER_RMFAIL
如何手动推进卡在PREPARED状态的XA事务
当MySQL崩溃重启后，有些XA事务停留在PREPARED状态，既没提交也没回滚，这时需要人工干预或脚本定期清理。系统不会自动决定该commit还是rollback——它不知道业务语义。
执行XA RECOVER能看到所有未决事务的xid，但注意：只有当前连接用户有SUPER或CONNECTION_ADMIN权限才能看到全部；普通用户只能看到自己发起的。
- 确认xid后，用
XA COMMIT 'xid'或XA ROLLBACK 'xid'手动结束 - 如果
XA RECOVER查不到某xid，但error log里有InnoDB: Transaction ... was in the XA prepared state，说明该事务已写入redo但未记入binlog，此时只能靠备份恢复，不可强行purge - MySQL 5.7+支持
innodb_force_recovery级别6绕过某些崩溃恢复，但会禁用XA事务，慎用
为什么JDBC里的setXAResource()经常出XAER_RMERR
这个错误多数不是MySQL的问题，而是JDBC驱动或应用服务器对XAResource生命周期管理不当。比如同一个XAResource被多个线程并发调用start()，或end()之后又调用了commit()。
典型场景：Spring声明式事务中混用@Transactional和手动UserTransaction；或者Tomcat JNDI配置了XA数据源，但代码里又用Connection.commit()而非xaResource.commit()。
- 确保每个
XAResource实例只被一个线程在一次全局事务中使用 - 不要在
XA START前执行任何非XA语句，否则驱动可能提前auto-commit，触发XAER_OUTSIDE - MySQL Connector/J 8.0.28+修复了部分
XAER_RMERR误报，旧版本建议升级
XA事务的性能和兼容性代价有多大
一次XA提交比本地事务多至少2次磁盘刷写（prepare + commit），且全程持有行锁到第二阶段结束，高并发下容易堆积PREPARED事务，拖慢整个实例吞吐。
更隐蔽的问题是复制延迟：MySQL主从复制不传递XA状态，从库看不到PREPARED事务，所以如果主库crash后切到从库，那些未决XA事务就永远丢失了——除非你用的是Group Replication或InnoDB Cluster这类自带分布式共识的方案。
- 单机多实例部署时，不同MySQL进程间XA不互通，
xid必须全局唯一且带服务标识，否则XA RECOVER会混淆 - Percona Server和MariaDB对XA的支持细节有差异，比如
XA RECOVER返回字段名不同，脚本移植前要验证 - 云数据库如RDS for MySQL通常禁用
XA RECOVER权限，且不保证崩溃后PREPARED事务可恢复
XA不是银弹，它把分布式一致性的复杂度从应用层推给了数据库和DBA。真正难的不是写XA START，而是设计出能在prepare失败、网络分区、节点反复上下线时仍能收敛的状态机。
