myisam引擎完全不支持xa分布式事务，因其未实现xa接口、无事务日志和状态机，执行xa prepare必报error 1399（xae00）；仅innodb通过两阶段提交与binlog协同保障一致性。
MyISAM 引擎根本无法参与 XA 两阶段提交——不是配置没开、不是权限不对、也不是版本太低，而是引擎层压根没实现 XA 接口。
MyISAM 执行 XA PREPARE 必报 ERROR 1399 (XAE00): XAER_RMFAIL
只要事务中任何一条 DML 涉及 MyISAM 表，XA PREPARE 就会立即失败。这不是“准备不充分”，而是 MyISAM 没有事务日志、没有状态机、也没有 prepare 阶段的持久化能力。InnoDB 能在 redo log 中标记 PREPARED 状态并等待 binlog 同步，MyISAM 连这个基础机制都不存在。
常见误判场景：
- 误以为只是没开
innodb_support_xa—— 该变量在 MySQL 5.7.10+ 已废弃，且只对 InnoDB 有效，对 MyISAM 完全无意义 - 在混合引擎事务里混用 MyISAM 和 InnoDB 表 —— 只要有一张 MyISAM 表，整个 XA 分支即被拒绝
- 看到
XA RECOVER返回空结果，以为是配置问题 —— 实际上事务根本没走到 prepare 阶段，自然不会出现在 recover 列表里
max_prepared_transactions=0 不是 MyISAM 的问题，但会让错误更难排查
MySQL 默认 max_prepared_transactions=0，这会禁用所有 XA 准备状态的持久化。它本身不影响 MyISAM 是否支持 XA（MyISAM 压根不走这一步），但会让错误信息变得模糊：你可能看到 XAER_RMFAIL，却分不清是引擎不支持，还是系统直接拒绝了 prepare 请求。
验证方式很简单：
- 执行
SHOW ENGINES，确认InnoDB行的XA列为YES，而MyISAM行的XA列为NO - 用
XA START 'xid'开启事务后，只操作 InnoDB 表，再执行XA PREPARE—— 成功；加入一条INSERT INTO myisam_table，再XA PREPARE—— 必报ERROR 1399
为什么 MySQL 内部 XA 也绕不开 InnoDB？
MySQL 的内部 XA（比如跨库事务或 binlog 与 redo log 一致性保障）依赖的是存储引擎级的两阶段提交能力。Server 层作为 TM，把 prepare 指令下发给各引擎 RM；只有 InnoDB 实现了完整的 handler 接口：prepare、commit_by_xid、rollback_by_xid。MyISAM 的 handler 接口里根本没有这些函数。
这意味着：
- 即使你在同一台 MySQL 上做
db1.innodb_table和db2.myisam_table的跨库更新，也无法用 XA 保证原子性 - MySQL 崩溃恢复时靠扫描 binlog 中的 XID 和 InnoDB 的 prepared 事务链表做比对 —— MyISAM 没 prepared 链表，也没 XID 存储机制，完全不参与这个流程
-
XA RECOVER查到的 xid 全部来自 InnoDB，MyISAM 相关操作在 XA 视角下是“非法中途退出”，不会留下任何可恢复痕迹
真正需要 XA 的场景（如金融类跨库写入），必须确保所有涉及表都是 InnoDB 引擎，且 max_prepared_transactions 已调大、binlog 开启、用户拥有 XA_RECOVER_ADMIN 权限——MyISAM 连入场券都没有，别在它身上浪费排错时间。
