mysql xa 悬挂事务的根本原因是2pc缺乏超时驱逐、跨节点状态同步及协调者故障恢复机制；xa prepare后崩溃导致重启“失忆”，日志有而内存无上下文，xa recover可查但xa commit报xaer_nota。
MySQL 的 XA 事务在分布式场景中产生悬挂事务，根本原因不是协议设计缺陷，而是两阶段提交（2PC）在真实网络与系统故障下的必然暴露——它没有内置的超时驱逐、跨节点状态同步或协调者故障恢复机制。
XA PREPARE 后崩溃，MySQL 重启就“失忆”
一旦执行 XA PREPARE，事务进入 PREPARED 状态，InnoDB 加锁但不落盘；此时若 mysqld 异常退出，重启后仅能从 binlog 或 XA log（如 mysql-bin.000001 中的 Xid_log_event）残留中读出 XID，但内存和 undo 中已无对应上下文。XA RECOVER 能查到，XA COMMIT 却报 XAER_NOTA，就是典型“日志有、内存无”。
- 这不是命令写错，是 MySQL 真的认不出这个 XID 了
- 常见触发点：客户端断连未发
XA END、网络闪断、应用进程被 kill -9、MySQL OOM 后强制终止 -
innodb_support_xa = OFF会导致XA RECOVER返回空——不是没悬挂，是压根不记
协调者单点失效，参与者无限等待
MySQL 本身不充当事务协调者（TM），它只是资源管理器（RM）。真正的 TM 是你的应用代码（比如 Java 里用 javax.transaction.xa.XAResource）、或中间件（如 Cetus、Seata）。一旦 TM 崩溃或失联，所有已 PREPARE 的 MySQL 节点就卡在“等指令”状态，锁不释放、连接不关闭、事务不推进。
- MySQL 默认不会主动清理长时间
PREPARED的事务（不像普通事务有wait_timeout） - 锁持有时间可能长达数小时甚至数天，阻塞后续 DML，引发连锁
Lock wait timeout exceeded - 主从复制中，从库不会自动回放
XA COMMIT/ROLLBACK（它们默认不写 binlog），导致主库“悬挂”，从库“不知情”
外部资源参与时，状态彻底脱节
当 XA 事务跨 MySQL + MQ + Redis 等异构系统时，MySQL 只管自己那一段 prepare 状态。如果 MQ 已 confirm 消息，而 MySQL 因网络问题没收到 commit，或者反过来，MySQL 已 prepare，MQ 却因超时 rollback，两边状态就永久不一致。
- 此时仅在 MySQL 执行
XA ROLLBACK或删日志，会直接破坏业务一致性 -
XA RECOVER输出的data字段是二进制，必须结合formatID、gtrid_length、bqual_length拼出完整 XID；单独复制data容易缺前导零或编码错误，导致人工核对失败 - 涉及外部系统时，必须先查 MQ 的事务消息状态、Redis 的预占 key 是否过期，再决定 MySQL 侧动作
真正难处理的不是“怎么清理”，而是“敢不敢清理”——因为 XA 悬挂的本质，是分布式系统里你永远无法 100% 确认其他节点当前状态。任何清理操作，都建立在人工交叉验证、业务逻辑可容忍的前提下。跳过这一步直接执行 innodb_force_recovery 或删 ib_logfile*，大概率把悬挂变成双写或数据丢失。
