MySQL XA事务在分布式场景中产生悬挂事务，根本原因是两阶段提交缺乏超时驱逐、跨节点状态同步及协调者故障恢复机制；XA PREPARE后崩溃导致重启“失忆”，日志有而内存无上下文，XA RECOVER可查但XA COMMIT报XAER_NOTA。
强一致性锁会让MySQL长时间阻塞写操作
分库分表后，一个业务（比如“下单+扣库存+减余额”）要跨多个物理库执行，如果用 XA PREPARE + XA COMMIT 这类强一致性方案，所有参与节点会在 PREPARE 阶段就锁定行、页甚至表级资源，直到协调者发出最终指令。这意味着：
- 只要有一个节点响应慢或网络抖动，整个事务卡在“准备就绪”状态，其他请求无法修改对应数据
-
FLUSH TABLES WITH READ LOCK类全局锁在备份时已显现出秒级写入阻塞问题，而 XA 的锁持有时间往往更长（尤其 Confirm/Cleanup 超时时） - InnoDB 的
innodb_lock_wait_timeout默认 50 秒，但分布式环境下超时判断更复杂，容易出现悬挂事务（XA RECOVER查到的PREPARED状态长期不清理）
协调者单点故障直接导致事务停滞
XA 协议依赖外部协调者（如 MySQL Router、Seata 或自研 TM），一旦它宕机或网络隔离，所有处于 PREPARED 状态的事务就失去指挥：
- 参与者不会自动回滚，也不会自行提交，只能靠人工干预或定时任务扫描
XA RECOVER结果 - 若协调者恢复前有节点重启，该节点上未清理的
PREPARED事务可能被忽略，造成数据不一致 - 没有内置的超时自动回滚机制，
innodb_rollback_on_timeout对 XA 事务无效
高并发下性能断崖式下降
实测中，当分片数 ≥ 3、TPS > 500 时，XA 方案吞吐量常不足本地事务的 1/5：
- 每个 XA 事务至少产生 2 次网络往返（Prepare → Commit/Rollback），跨 IDC 延迟放大影响显著
- Prepare 阶段需写 binlog + redo log + sync 到磁盘，且不能复用组提交优化（因各节点事务 ID 不同）
- MySQL 8.0 虽支持
XA OPTIMIZE，但仅减少部分日志刷盘开销，无法解决根本的同步阻塞问题
真正难处理的是悬挂事务和幂等缺失
线上最头疼的不是“失败”，而是“卡住”：
- 应用层调用
XA COMMIT后网络中断，MySQL 实际已提交但客户端没收到响应，重试又触发重复提交 - Confirm 阶段要求幂等，但 MySQL 原生不提供幂等语义，必须靠业务层加唯一索引或状态机控制
- Cancel 阶段若失败，冻结的库存/余额无法释放，需依赖独立的补偿任务——而这本身又引入新的一致性问题
跨库事务里，“锁住一切等结果”听起来稳妥，实际是把可用性押在最脆弱的链路上。多数业务能容忍几秒内的不一致，却无法承受一次协调者抖动带来的分钟级写入不可用。
