xa start 后必须显式执行 xa end，否则事务卡在 active 状态，阻塞 xa prepare 并可能导致连接池耗尽；xa end 后不可再执行 dml；xa prepare 失败需人工通过 xa recover 干预；mysql 8.0.29+ 并行复制需设 binlog_transaction_dependency_tracking=commit_order；java 中勿依赖 iswrapperfor，应显式获取 xaresource。
XA START 之后必须显式执行 XA END，否则事务会卡住
MySQL 的 XA 事务不是自动管理的，XA START 只是开启一个全局事务分支，不提交也不回滚，后续必须配对调用 XA END 才能进入准备阶段。漏掉这步，事务状态会一直停留在 ACTIVE，阻塞后续 XA PREPARE，甚至导致连接池耗尽。
常见错误现象：XA RECOVER 查到一堆 ACTIVE 状态事务；应用日志里反复出现 Lock wait timeout exceeded；XA PREPARE 报错 ERROR 1399 (XAE04): XAER_RMFAIL。
- 务必在业务逻辑完成、所有 DML 执行完后立即调用
XA END，不能依赖连接关闭或超时清理 -
XA END后不能再执行任何 DML，否则报ERROR 1397 (XAE05): XAER_RMFAIL - 建议把
XA START/XA END/XA PREPARE/XA COMMIT封装进带 panic 捕获的函数，避免异常跳过关键步骤
XA PREPARE 失败时，必须用 XA RECOVER 检查并人工干预
XA PREPARE 是两阶段提交的临界点：成功意味着资源已锁定、日志已刷盘、可以持久化回滚；失败则说明某个参与方拒绝了准备，整个事务必须整体回滚。但 MySQL 不会自动清理失败的 prepare 状态，也不会通知其他节点——它只等你来查。
使用场景：跨库更新（比如订单库 + 库存库），其中一个库磁盘满、binlog 写失败、或网络临时中断，都可能导致 XA PREPARE 返回错误但事务仍留在 PREPARED 状态。
- 上线前必须配置定时任务，定期执行
XA RECOVER，检查输出中是否有FORMATID和GTRID_LENGTH非零但未提交/回滚的记录 -
XA RECOVER结果里的DATA字段是 base64 编码的 XID，需解码确认对应业务单号，避免误操作 - 对长期处于
PREPARED的事务，不能直接XA ROLLBACK——先确认另一端是否已提交；否则可能引发数据不一致
MySQL 8.0.29+ 的 binlog_transaction_dependency_tracking 影响 XA 日志顺序
启用并行复制时，MySQL 默认开启 binlog_transaction_dependency_tracking = WRITESET，它会重排事务写入 binlog 的顺序以提升从库吞吐。但这会破坏 XA 事务的全局顺序语义：两个 XA 分支的 XA PREPARE 在主库按 A→B 执行，但在从库可能被重排为 B→A，导致从库上 XA COMMIT 失败或状态不一致。
性能与兼容性影响：该问题在主从架构 + XA + 并行复制共存时必现，且无法通过调整 slave_parallel_workers 规避。
- 若必须用 XA，主库应设
binlog_transaction_dependency_tracking = COMMIT_ORDER或DISABLED - 从库无需改此参数，但需确保
slave_parallel_type = LOGICAL_CLOCK且slave_preserve_commit_order = ON - 该配置会略微降低主库 binlog 写入并发度，但换来的是 XA 状态可预测——这点代价值得
Java 应用里用 JTA 调 XA，别信 Connection.isWrapperFor(XAResource.class)
很多 Java 框架（Spring Boot + Atomikos）默认用 Connection.isWrapperFor(XAResource.class) 判断是否支持 XA，但 MySQL Connector/J 8.0.23+ 对该方法返回 false，即使底层完全支持 XA。这不是 bug，是驱动故意为之：它要求你显式获取 XAResource 实例再调用 start()，否则不触发 XA 协议握手。
容易踩的坑：应用启动不报错，事务看起来也“提交”了，但 XA RECOVER 查不到记录，实际没走两阶段——因为框架跳过了 XA 流程，退化成本地事务。
- 不要依赖
isWrapperFor，直接从DataSource获取XAResource，例如((MysqlXADataSource) ds).getXAConnection().getXAResource() - 确保
xa_datasource配置中包含pinGlobalTxToPhysicalConnection=true，否则多线程下 XID 可能错乱 - 测试阶段必须连上 MySQL 手动执行
XA RECOVER，确认有真实 XID 记录，而非仅靠日志“commit success”判断
