mysql xa事务是单实例内对2pc协议的实现，非天然跨库；跨库需应用层协调多个实例的xa分支，且mysql不提供tm功能，xa recover需process权限及合法xid格式。
XA事务不是“跨库事务”的代名词，而是MySQL对2PC协议的具体实现
很多人一看到XA就默认是“分布式事务”，其实这是个常见误解。MySQL的XA START命令本身不涉及网络通信、不连接其他数据库，它只是在单个MySQL实例内启用XA协议语义。真正构成跨库事务，需要你手动在多个MySQL连接（甚至不同实例）上分别执行XA START、XA PREPARE和XA COMMIT，并由外部协调者（比如应用层或Seata）统一调度——MySQL自身不提供跨实例的TM功能。
也就是说：XA是接口规范，2PC是流程逻辑，而“分布式”取决于你是否真正在多个RM上运行它们。
- 单实例下用
XA：主要用于调试、验证2PC行为，或配合MySQL内部崩溃恢复机制（如binlog与redo log一致性） - 多实例下用
XA：必须由应用/中间件维护全局xid一致性，并确保所有分支的gtrid相同、bqual可区分 - MySQL不自动管理xid生命周期：不会清理已
PREPARE但长期未COMMIT/ROLLBACK的事务，需定期用XA RECOVER检查并人工干预
prepare阶段到底做了什么？别只看SQL执行成功
XA PREPARE不是“把SQL跑完就完事”，它触发的是InnoDB和Server层的协同动作：
- InnoDB将事务修改写入
redo log，并标记为PREPARED状态（非COMMITTED），此时数据页尚未刷盘，行锁仍持有 - Server层将该事务的binlog事件写入缓存（
binlog_cache），但不fsync到磁盘——这一步是关键，它让binlog和redo log在崩溃时能通过2PC恢复逻辑对齐 - 只有这两步都完成，才向客户端返回
OK；任一失败，直接回滚，不进入PREPARED状态
所以如果你看到XA PREPARE成功，不代表数据已持久化，也不代表能被其他会话读到（隔离级别仍生效）。它只代表：“我已留好位置，等你发最终指令”。
commit和rollback不是对称操作，失败路径完全不同
XA COMMIT和XA ROLLBACK在底层处理差异很大，直接影响恢复行为：
-
XA COMMIT：先刷binlog到磁盘（fsync），再更新redo log状态为COMMITTED。如果在这之间崩溃，重启后MySQL会扫描redo log中处于PREPARED状态的事务，并检查binlog是否完整——有则提交，无则回滚 -
XA ROLLBACK：直接清除redo log中的PREPARED记录，不碰binlog缓存。它不依赖binlog存在性，也不需要fsync - 注意：
XA ROLLBACK不能用于已COMMIT但未同步到从库的场景——那是复制延迟问题，不是XA事务状态问题
XA recover看不到事务？可能是格式或权限问题
XA RECOVER查不到你刚PREPARE的事务，别急着怀疑MySQL坏了。先确认这三点：
- xid格式非法：
gtrid长度不能超过64字节，且不能含不可见字符；推荐只用ASCII字母、数字、下划线，例如'order_20260903_001' - 连接用户缺少
PROCESS权限：XA RECOVER需要该权限，否则返回空结果（不是报错） - 事务已自动清理：如果
XA PREPARE后超时（默认innodb_lock_wait_timeout影响不大，但长时间idle可能被kill），MySQL不会主动回滚，但某些运维脚本或监控工具可能调用KILL导致连接中断，PREPARED状态丢失
最稳妥的验证方式是：在同一个连接中执行XA START→SQL→XA END→XA PREPARE后，立刻执行XA RECOVER，避免连接断开或超时干扰。
真正容易被忽略的点是：MySQL的XA事务状态不跨连接持久化。一旦客户端连接断开，PREPARED状态虽然保留在存储引擎里，但XA RECOVER仍能查到；可如果你用另一个用户登录，没权限就看不到——它不像普通表数据那样“公开可见”。
