MySQL 8.4 XA 事务卡在 PREPARED 怎么排查：状态核对、恢复与超时边界

订单服务调用支付服务时，如果两边使用 XA 事务，最让值班人员紧张的不是普通回滚，而是 MySQL 里出现了长时间的 PREPARED 分支：连接早已断开，锁还在，业务表却不能判断这笔订单究竟该提交还是取消。

下面用一笔订单支付场景说明排查顺序。示例只讨论 MySQL 8.4 InnoDB 参与 XA 时的状态判断，不把 XA 当成所有跨服务一致性的万能方案。

PREPARED 为什么会把锁留在数据库里

XA 常见流程是：应用以全局事务 ID 开始分支，完成本地写入后执行 XA END 和 XA PREPARE，协调器确认所有参与者都准备成功，再发出 XA COMMIT。如果协调器在 prepare 后崩溃或网络中断，MySQL 只能等待后续决定。

XA START 'pay-20260823-001', 'mysql-order', 1;
UPDATE orders SET pay_state = 'checking' WHERE id = 9001;
XA END 'pay-20260823-001', 'mysql-order', 1;
XA PREPARE 'pay-20260823-001', 'mysql-order', 1;

此时事务可能已经持有行锁。重新建立普通连接并执行 ROLLBACK 不会结束它，因为 XA 分支不属于这个新连接的普通事务上下文。

先用 XA RECOVER 找到分支，不要先猜结果

第一步是只读核对：

XA RECOVER;

输出通常包含格式、全局事务 ID 长度、分支限定符长度和数据内容。不同客户端对二进制字段的展示可能不同，所以应记录原始输出、执行时间和实例名，不能只复制一段看不懂的字符串。

SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id
FROM information_schema.innodb_trx
WHERE trx_state IN ('RUNNING', 'LOCK WAIT');

innodb_trx 可以帮助观察相关 InnoDB 事务和开始时间，但它不是 XA 全局事务的完整目录。两份结果应结合查看：一个用于确认数据库侧仍有事务，一个用于确认可恢复的 XA 分支。

提交还是回滚必须对照协调器和业务记录

看到分支后，不要因为订单现在显示“支付中”就直接提交，也不要因为超时就直接回滚。正确判断至少要找三份证据：

只有当协调器明确记录了 commit 决定，才考虑补发提交；如果记录的是 rollback，则应回滚；协调器和业务记录都丢失时，应该进入人工确认和隔离流程，而不是按“时间最长”自动选一个动作。

恢复动作与回归检查

确认最终决定后，再执行与原分支完全匹配的恢复命令：

-- 已确认协调器的最终决定为提交
XA COMMIT 'pay-20260823-001', 'mysql-order', 1;

-- 只有确认应取消时才使用
-- XA ROLLBACK 'pay-20260823-001', 'mysql-order', 1;

恢复命令返回成功只是第一道检查。至少还要做以下复查：

• 再次执行 XA RECOVER，确认目标分支不再出现。
• 查询 performance_schema.data_locks 或业务锁等待指标，确认长锁已释放。
• 核对订单、支付单和库存状态，确认没有停在“支付中”却已扣款的矛盾状态。
• 检查消息消费日志，给重复通知保留幂等键，不要因为补发而重复记账。

如果分支数量持续增长，应先限制新的 XA 流量并定位协调器故障。把清理脚本设置成“发现 PREPARED 超时就自动回滚”看似省事，却可能把已经成功扣款的事务变成跨系统不一致。

常见问题

XA PREPARED 状态会不会因为连接断开自动消失？

不会把它当成普通事务自动回滚。prepare 后的分支需要最终的提交或回滚决定，连接重建不能代替协调器完成这一步。

XA RECOVER 查不到分支就能认定事务已结束吗？

不能。还要结合实例、存储引擎、执行时间和协调器日志确认，避免查错库或遗漏已经转入业务补偿流程的记录。

能不能按 PREPARED 持续时间自动回滚？

除非业务已经定义并验证了超时补偿协议，否则不建议。持续时间只能说明它等待很久，不能说明最终业务决定。

把 PREPARED 当成一致性事故信号

MySQL XA 的排查重点不是背下两条恢复命令，而是把全局事务 ID、协调器决定和业务状态对应起来。先只读取证，再执行唯一匹配的提交或回滚，最后复查分支、锁和幂等结果，才能把一次连接故障收敛成可审计的恢复动作。