xa recover仅读取binlog/xa log残留，不反映实时内存状态；必须先查information_schema.innodb_trx where trx_state='prepared'确认事务是否真存活，否则xid为幽灵记录，不可直接提交或回滚。
XA RECOVER只显示残留，不等于事务还活着
执行 XA RECOVER 看到一堆 XID，不代表这些事务还在内存中运行。MySQL 5.7 的 XA RECOVER 仅从 binlog 或 mysql-bin.* 中的 Xid_log_event 提取残留记录，重启后若未完成 prepare 阶段的上下文重建，InnoDB 内存里早已没有对应 trx_state = 'PREPARED' 的条目。
必须先查真实状态：
- 运行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'PREPARED'—— 有结果才说明事务真在内存中“活着”，可安全尝试XA COMMIT或XA ROLLBACK - 若返回空，但
XA RECOVER有输出，基本是“幽灵 XID”：日志残留 + 内存失忆，不能直接操作，否则可能误删其他节点已提交的痕迹 -
SHOW ENGINE INNODB STATUS的 TRANSACTIONS section 里搜PREPARE关键字，看是否有崩溃线索（如*** ERROR: during recovery）
拼XID必须用formatID/gtrid_length/bqual_length三者还原
XA RECOVER 输出的 data 字段是 base64 编码的二进制内容，且默认截掉前导零、不带格式标识。单独复制粘贴 data 值去人工比对业务 XID（比如 service:order:20260930001），极大概率失败。
正确做法是结合三列字段还原完整 XID：
-
formatID：决定编码方式，常见为 1（表示标准 ASCII） -
gtrid_length和bqual_length：告诉你要从data的哪一段取 gtrid（全局事务 ID）、哪一段取 bqual（分支限定符） - 推荐用 Python 快速验证：
import base64; bytes_data = base64.b64decode("xxx"); print(bytes_data.hex())，再对照 hex 值转 ASCII 确认是否匹配业务标识
别信 PROCESSLIST，重点盯 INNODB_TRX + metadata_locks
悬挂 XA 事务常伴随元数据锁（MDL）阻塞，但持有锁的连接在 SHOW PROCESSLIST 里可能是 Command = 'Sleep'，INFO 为空，TIME 却长达数小时——这是典型的应用端断连后未清理事务。
必须联合查：
-
SELECT * FROM sys.schema_table_lock_waits：直接看到blocking_pid和waiting_pid，定位谁卡了 DDL -
SELECT t.*, p.COMMAND, p.TIME, p.INFO FROM INFORMATION_SCHEMA.INNODB_TRX t JOIN INFORMATION_SCHEMA.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID WHERE p.COMMAND = 'Sleep' AND t.trx_state = 'RUNNING'：揪出那些“睡着却没提交”的连接 -
SELECT * FROM performance_schema.metadata_locks WHERE OWNER_THREAD_ID = xxx：确认该线程是否仍持MDL_SHARED_READ或MDL_EXCLUSIVE锁
外部系统状态没验证前，禁止执行XA ROLLBACK
MySQL 本身只是资源管理器（RM），不是协调者（TM）。一个 XA 事务若由 Spring Boot 的 JtaTransactionManager、Seata 或 Cetus 驱动，其最终状态取决于外部 TM 的决策。你在 MySQL 单方面执行 XA ROLLBACK，等于绕过协调逻辑，直接覆盖下游已确认的状态。
动手前必须交叉验证：
- 查 MQ 消费位点：Kafka 查
__consumer_offsets对应 group 的 offset；RocketMQ 查事务消息的check状态 - 查 Seata：看
undo_log表里对应xid是否已log_status = 1（已提交） - 查应用日志：用 trace ID 匹配时间戳与
XA RECOVER中的gtrid，确认当时应用是否发出了 commit 指令 - 如果是 Cetus 中间件，必须用其
xa-suspension-tool工具，它会自动比对 binlog 与各分片库状态，而非直连 MySQL 执行命令
MySQL 5.7 虽支持 innodb_force_recovery = 1 跳过 prepare 校验后强制 rollback，但前提是确认该 XID 在所有外部系统中都未提交——这点最难验证，也最容易被跳过。
