xa recover是唯一能列出mysql中未提交xa事务的命令，它读取innodb xa日志，返回formatid、gtrid_length、bqual_length和拼接的data字段；结果非空即存在悬挂事务，需依长度切分data构造xid执行rollback/commit，且处置权属业务方或协调器，不可dba单方面决定。
如何用 xa recover 查看残留的 XA 事务
MySQL 中未提交的分布式事务（XA）不会出现在 information_schema.innodb_trx 或 SHOW PROCESSLIST 里，必须用专用命令检测。xa recover 是唯一能列出当前所有待决 XA 事务的命令，它读取的是 InnoDB 的 XA 事务日志，不依赖会话状态。
执行后返回结果类似：
+------------+--------------+--------------+----------------------------------------------------------+ | formatID | gtrid_length | bqual_length | data | +------------+--------------+--------------+----------------------------------------------------------+ | 1096044365 | 34 | 22 | 10.10.10.10.tm16372115537412470010.10.10.10.tm881366 | +------------+--------------+--------------+----------------------------------------------------------+
只要结果非空，就说明存在未提交的 XA 事务。注意：xa recover 不需要事务处于活跃连接中，即使发起事务的客户端已断开，只要没 commit/rollback，它仍会被列出。
gtrid_length 和 bqual_length 决定 XA 操作语法
XA 事务的 data 字段是拼接字符串，gtrid_length 和 bqual_length 是切分依据 —— 这个细节极易出错，直接复制 data 值去 xa rollback 会报错 ERROR 1397 (XAE04): Unknown error。
- 若
gtrid_length > 0且bqual_length = 0：说明是简化格式，可直接用xa rollback 'xxx'，其中'xxx'就是data全值 - 若
gtrid_length > 0且bqual_length > 0：必须手动切分 ——gtrid是data前gtrid_length个字符，bqual是末尾bqual_length个字符，中间部分丢弃 - 切分错误会导致
xa commit或xa rollback失败，且无法回退；InnoDB 不校验语义，只按字节匹配
为什么不能单独决定 XA 事务该 commit 还是 rollback
XA 事务跨多个 MySQL 实例时，单个节点上的残留事务**没有上下文信息**来判断全局意图。比如转账场景中，A 实例上一个未提交的 XA 事务，可能对应 B 实例上已 prepare 成功但尚未收到协调器指令的状态。
运维强行执行 xa commit 或 xa rollback 的风险包括：
- 只在 A 实例 rollback，而 B 实例最终 commit → 钱转出但未到账
- 只在 A 实例 commit，而 B 实例因网络问题最终 rollback → 钱到账但未扣款
- 事务协调器（如 Seata、Atomikos）可能仍在重试或等待超时，人工干预会破坏其状态机
所以 xa recover 只是发现手段，处置权必须交还业务方或分布式事务协调器，不能由 DBA 单方面决策。
如何避免 XA 事务残留
XA 事务残留通常源于应用层异常退出、网络闪断或协调器宕机，而非 SQL 执行错误。预防比事后处理更关键：
- 应用代码中，XA start 后必须配对调用
xa end→xa prepare→xa commit/xa rollback，任何一环缺失都可能导致残留 - 不要在连接池中复用已 start XA 的连接；MySQL 不允许同一连接重复 start XA，但旧事务状态可能滞留
- 监控层面定期执行
xa recover并告警非空结果，响应时间应小于 XA 事务的业务超时阈值（例如 30 秒） - MySQL 8.0.23+ 支持
innodb_lock_wait_timeout对 XA prepare 阶段生效，但不解决 commit/rollback 缺失问题
XA 事务的原子性保障不在单个 MySQL 节点，而在整个分布式协调链路；看到 xa recover 输出，第一反应不应该是“怎么 rollback”，而是“谁在管这个全局事务”。
