不必须，但跳过 xa end 会导致事务卡在 active 状态，使后续 xa prepare 报错 xaer_rmfail；mysql xa 严格遵循 start→end→prepare→commit/rollback 状态机。
MySQL XA START 之后必须用 XA END 吗？
不必须，但跳过 XA END 会导致事务状态卡在 ACTIVE，后续 XA PREPARE 直接报错 ERROR 1399 (XAE04): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state。
MySQL 的 XA 实现严格遵循两阶段提交状态机：必须按 XA START → XA END → XA PREPARE → XA COMMIT/ROLLBACK 顺序推进。中间缺一环，状态就断掉。
-
XA START 'tx1'后，事务进入ACTIVE，此时只能执行 DML，不能直接PREPARE -
XA END 'tx1'是显式标记“业务逻辑结束”，将状态转为IDLE，才允许下一步 - 如果用存储过程或应用层自动包裹，容易漏掉
END—— 这是线上查不到日志、事务悬停的最常见原因
XA PREPARE 失败后，XA RECOVER 看不到记录？
可能因为事务未真正进入 prepared 状态，或者 MySQL 服务重启过导致内存中 prepare 列表丢失 —— XA RECOVER 只返回当前内存里还活着的 prepared 分支，不读磁盘日志。
MySQL 的 XA prepare 并不立即将事务写入磁盘（除非开启 innodb_support_xa=ON 且刷盘策略生效），它依赖 InnoDB 的崩溃恢复机制来重建 prepared 列表。如果崩溃发生在 PREPARE 后但未刷盘，重启后 XA RECOVER 就为空。
- 确认配置：检查
innodb_support_xa是否为ON（5.7+ 默认 ON，但某些云厂商会关） - 检查错误日志：
XA PREPARE失败时通常伴随InnoDB: Error: failed to prepare transaction类提示 - 不要依赖
XA RECOVER做最终一致性判断 —— 它只是运维辅助命令，不是分布式事务的状态权威源
跨 MySQL 实例的 XA 事务能真正保证原子性吗？
理论可以，实际极难落地。MySQL XA 本身只管单实例内协调，跨实例需外部协调者（比如应用自己当 TM），而 MySQL 不提供标准 TM 接口，也没有全局事务日志同步机制。
典型问题出在第二阶段：一个分支 XA COMMIT 成功，另一个因网络超时失败，MySQL 不会自动回滚已 commit 的分支，也没有反向补偿能力。
- 所有参与节点必须同时在线，且网络稳定 —— 生产环境几乎无法满足
- 没有超时自动 abort 机制：
XA PREPARE后挂起数小时，其他节点无法感知，也没法强制清理 - 备份与主从切换会破坏 XA 状态：从库不复制 XA 事务的 prepare 状态，failover 后原 prepared 分支彻底丢失
为什么 Java 应用调用 XA 时经常卡在 Connection.commit()？
本质是 JDBC 驱动把 XAResource.commit(xid, false) 映射成底层 XA COMMIT 命令，而该命令在 MySQL 侧会阻塞等待所有分支响应 —— 如果任一分支不可达或未 PREPARE，就会一直 hang。
MySQL 的 XA COMMIT 不带超时参数，JDBC 层也无法透传 timeout，所以一旦卡住，只能靠连接超时（如 socketTimeout）被动中断，但中断后状态更不可控。
- 避免在高延迟网络下用 XA：比如跨 AZ 调用，RT > 200ms 就大概率触发 hang
- 不要复用同一
Xid多次调用commit()—— MySQL 不校验重复提交，但驱动可能抛XAER_NOTA - 真要用，务必配合
setNetworkTimeout()设置 Socket 级超时，并捕获XAException.XA_RBTIMEOUT做人工干预
XA 在 MySQL 里是个“协议可用、工程难稳”的功能。它暴露的是接口，不是解决方案。真正要落地，得自己补监控、补重试、补日志对账 —— 这些都不是 XA COMMIT 能帮你做的。
