MyISAM不支持XA事务，因其根本未实现XA接口，无事务日志（redo/undo）和事务状态机，执行XA PREPARE即报ERROR 1399；仅InnoDB通过与binlog协同支持两阶段提交。
MyISAM 根本不实现 XA 接口，XA PREPARE 会直接报错
MyISAM 没有事务日志（redo/undo），也不维护事务状态机，所以它压根不响应 XA 协议的任何命令。只要你在 MyISAM 表上执行 XA START 后跟 XA PREPARE，MySQL 就会立刻返回错误：ERROR 1399 (XAE00): XAER_RMFAIL。这不是配置问题，是引擎层面缺失能力——MyISAM 连“准备”这个阶段都无法进入，更谈不上两阶段提交。
常见误操作包括：混合使用 InnoDB 和 MyISAM 表的 XA 事务、或建表时没确认引擎类型就直接写 XA 语句。只要语句涉及任意 MyISAM 表，整个 XA 分支就非法化。
- 用
SHOW CREATE TABLE t1确认表引擎，别依赖默认值 -
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t1'是更稳妥的检查方式 - MyISAM 表无法参与任何需要崩溃恢复一致性的流程，包括主从复制中的 XA 回放
InnoDB 支持 XA 是因为它和 binlog 共同构成 2PC 的两个参与者
InnoDB 的 XA 实现不是孤立的：它把自身（作为资源管理器 RM）和 MySQL Server 层的 binlog（作为另一个 RM）一起注册进同一个全局事务 ID（xid）。只有这样，崩溃恢复时才能靠 binlog 中的 XA PREPARE 记录，驱动 InnoDB 完成未决事务的提交或回滚。
这个协同机制要求 binlog 必须记录 XA 事务的 prepare 阶段，而 MyISAM 完全不产生这类日志事件，也无法被 binlog 捕获状态变化。所以即使你绕过语法报错强行让 MyISAM “参与”，MySQL 内部也无法把它纳入两阶段协调流程。
-
binlog_format=STATEMENT时，InnoDB 的 XA 也可能失败（尤其含非确定函数），但 MyISAM 连这一步都走不到 - InnoDB 的
XA RECOVER能列出 prepared 状态事务，MyISAM 表所在连接里查不到任何结果 - 崩溃后，InnoDB 可根据 binlog + redo log 做原子恢复；MyISAM 只能靠
myisamchk修复，且无法保证跨表一致性
MyISAM 缺失事务日志导致 binlog 无法建立 XA 一致性锚点
MySQL 的 XA 崩溃恢复安全，本质依赖一个“一致性锚点”：binlog 中的 XA PREPARE 事件必须与 InnoDB redo log 中对应事务的 prepare 状态严格对齐。InnoDB 通过 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1 保证两者同时落盘。
MyISAM 没有 redo log，所有写入直落磁盘，没有 prepare 状态可持久化，binlog 也就无从记录该事务的中间状态。这意味着：一旦 crash 发生在 MyISAM 写入完成但 binlog 还没写入的瞬间，主库重启后 binlog 里没有这条事务的任何痕迹，但从 MyISAM 文件看数据已变更——彻底打破“要么全有、要么全无”的分布式语义基础。
- MyISAM 的
INSERT/UPDATE在崩溃后可能部分生效，无法回滚，binlog 也无对应事件可同步到从库 - 即使人为用
FLUSH TABLES WITH READ LOCK配合mysqldump，也只能做最终一致性快照，不是实时 XA 一致性 - 华为云等增强版 MySQL 对 XA 崩溃恢复的修复，全部基于 InnoDB + binlog 的双日志对齐逻辑，MyISAM 不在此支持范围内
真正影响 XA 可用性的不是引擎开关，而是 binlog 与存储引擎的协同粒度
很多人还在找 innodb_support_xa 参数，但它早在 MySQL 8.0.13 就被删了。现在 XA 是否可用，只取决于三件事：是否用 InnoDB 表、binlog_format 是否为 ROW 或 MIXED、以及是否显式执行了 XA PREPARE。MyISAM 连第一个条件都不满足。
更关键的是：XA 在 MySQL 中只是协议接口，不解决分布式系统级问题（比如协调者宕机、网络分区）。它只保证“单个 MySQL 实例内，InnoDB 和 binlog 之间的一致性”。想跨多个 MySQL 实例做分布式事务，必须用外部事务管理器（如 Seata），而这些组件也明确要求所有参与者使用 InnoDB。
- MyISAM 表不能出现在任何 XA-aware 的中间件（如 ShardingSphere-XA）的路由规则中
- 应用层若用 JTA，
XADataSource绑定的必须是 InnoDB 引擎的库 - 哪怕只读场景，MyISAM 也无法提供 MVCC 或 consistent read，跟 XA 的隔离性目标天然冲突
