MySQL XA事务的PREPARED状态不可迁移，因其仅存于内存且不持久化；迁移前必须在源库执行XA COMMIT或XA ROLLBACK终结所有XA事务，否则目标库无法识别；真正需迁移的是分布式协调器（如Seata、Atomikos）的日志，而非MySQL自身状态。
MySQL XA 事务状态不能直接迁移
XA 事务的 PREPARED 状态只存在于本地 MySQL 实例内存和 mysql.innodb_locks（或 INFORMATION_SCHEMA.INNODB_TRX）中，不持久化到磁盘，也不跨实例同步。一旦 mysqld 重启，所有 PREPARED 状态都会丢失，后续 XA COMMIT 或 XA ROLLBACK 会报错 ERROR 1399 (XAE04): XAER_NOTA: Unknown XID。
迁移前必须先清理或完成所有 XA 事务
没有“迁移状态”这回事，只有“在源库上终结它”。否则目标库根本不知道这些 XA 分支的存在。常见错误是 dump + restore 后发现 XA RECOVER 在新实例里查不到任何记录——因为 PREPARED 状态压根没被保存。
- 执行
XA RECOVER查出所有待处理 XID - 对每个 XID 显式调用
XA COMMIT xid或XA ROLLBACK xid（需业务侧确认语义） - 若应用已下线、无法判断该提交还是回滚，且数据一致性要求高，应从备份恢复到故障前一致点，而非强行续跑
分布式协调器（如 Seata、Atomikos）才是迁移关键
真正需要迁移的是协调器里的事务日志，不是 MySQL 本身的 XA 状态。MySQL 只是资源管理器（RM），它不保存全局事务生命周期信息。
- Seata 的
branch_table和global_table必须随协调器一起迁移，且需保证与 MySQL RM 注册的 branch_id 一一对应 - Atomikos 使用
jta.properties配置日志路径，迁移时要同步拷贝com.atomikos.icatch.output_dir指向的目录 - 若协调器日志损坏或缺失，MySQL 上残留的 PREPARED 事务只能人工干预：查 binlog 找原始 XA START 时间点，结合业务日志推断动作意图
避免在生产环境依赖纯 MySQL XA 做跨库事务
MySQL 原生 XA 缺少超时自动决议、跨机房容灾、协调器高可用等能力。实际出问题时，PREPARED 卡住、节点失联、重启丢状态，都是常态。
- 不要把
XA START放在长事务或网络不稳链路中 - 禁止在主从架构中对从库执行 XA 操作（从库不支持
XA COMMIT） - 监控必须覆盖
SHOW ENGINE INNODB STATUS中的TRANSACTIONS区块，抓取STATE = 'PREPARED'的异常堆积
XA 状态本身不可迁移，能迁的只有协调逻辑和决策依据。漏掉协调器日志，或者跳过清理 PREPARED 状态就切流，后面查不到 XID 是最轻的后果。
