myisam 表执行 xa prepare 直接报错 error 1399，因其未实现 xa 接口、无事务状态机和 redo/undo 日志，根本无法进入准备阶段；只要涉及任意 myisam 表，整个 xa 分支即失效，且无法参与崩溃恢复与主从一致性保障。
MyISAM 表执行 XA PREPARE 直接报错 ERROR 1399
MyISAM 根本没实现 XA 接口，连“准备”阶段都进不去。只要语句涉及任意 MyISAM 表，XA PREPARE 就会立刻返回 ERROR 1399 (XAE00): XAER_RMFAIL。这不是配置或权限问题，是引擎层缺失能力——没有事务状态机、没有 redo/undo 日志，压根不响应 XA 协议。
常见误操作包括：
- 建表时没确认引擎类型，直接写
XA START+INSERT INTO myisam_table - 混合使用 InnoDB 和 MyISAM 表的 XA 事务（哪怕只有一张 MyISAM 表，整个分支就非法）
- 依赖
SHOW CREATE TABLE看默认引擎，但实际建表语句可能显式指定 ENGINE=MyISAM
MyISAM 没有事务日志，无法参与崩溃恢复一致性锚点
InnoDB 的 XA 一致性依赖 binlog 中的 XA PREPARE 事件与 redo log 中 prepare 状态严格对齐。这个“一致性锚点”要求两者同时落盘（靠 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1 保证）。MyISAM 没有 redo log，所有写入直落磁盘，既无 prepare 状态可持久化，也无法被 binlog 捕获状态变化。
结果就是：
- 崩溃后无法原子恢复：InnoDB 可靠，MyISAM 只能靠
myisamchk修复，且无法保证跨表一致性 -
XA RECOVER查不到任何结果：MyISAM 表所在连接里，根本不会生成 prepared 事务记录 - 主从复制中 XA 回放失败：MyISAM 修改无法在从库重建 prepare 状态，复制链路断开
MyISAM 表无法满足分布式事务的底层约束前提
分布式事务不是单纯“多库一起提交”，它要求每个参与者都能独立维护事务状态、支持两阶段协调、并在崩溃后可重入决策。MyISAM 连最基本的前提都不满足：
- 无外键约束：引用完整性需应用层硬编码，出错概率高
- 无行级锁：只有表锁，高并发下易阻塞，且无法支撑
SELECT FOR UPDATE等隔离控制 - 自动提交不可关闭：
BEGIN/COMMIT对 MyISAM 是空操作，DML 立即生效，无法组合成原子单元 - 并发写入直接覆盖：两个请求同时
UPDATE同一行，后写入者覆盖前值，丢失更新
替代方案不是“让 MyISAM 支持 XA”，而是绕开它
真要解决一致性问题，得从存储引擎层切换或架构层规避：
- 转换引擎：
ALTER TABLE t1 ENGINE = InnoDB，注意评估索引重建耗时和锁表影响 - 检查现有表：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t1'，比依赖默认值更稳妥 - 若必须保留 MyISAM（如只读报表库），则分布式事务逻辑不能包含它；写操作全部路由到 InnoDB 库，MyISAM 仅作最终快照消费
- 跨实例场景下，MySQL 本身不提供全局协调器，XA 仅限单实例内多引擎协作；跨库一致性必须靠应用层补偿（如本地消息表 + MQ）或中间件（Seata/DTM）
最容易被忽略的是：MyISAM 在分布式事务里不是“弱一致性”，而是“无一致性契约”。它根本不参与协议协商，也不暴露状态接口——不是慢，是缺席。
