MyISAM不支持XA事务，因其未实现XA接口、无事务日志和状态机，执行XA PREPARE即报ERROR 1399；仅InnoDB通过与binlog协同支持两阶段提交。
MyISAM 引擎根本不支持 XA 分布式事务——这不是配置问题，也不是版本差异，而是引擎层彻底缺失实现。只要语句涉及任意 MyISAM 表，XA PREPARE 就会立刻报错 ERROR 1399 (XAE00): XAER_RMFAIL，整个 XA 分支直接失效。
确认表引擎类型，别信默认值
很多人以为建表没指定 ENGINE 就是 InnoDB，但老库或迁移库中大量存在隐式 MyISAM 表。仅靠 SHOW CREATE TABLE t1 看一眼不够稳妥：
-
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t1'是唯一可靠方式 - 批量检查所有表：
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE ENGINE = 'MyISAM'; - 特别注意视图、临时表、分区表子分区——它们可能各自用不同引擎，
XA START一碰到 MyISAM 分区就崩
ALTER TABLE ENGINE=InnoDB 失败的常见原因
即使你决心切到 InnoDB，ALTER TABLE t ENGINE=InnoDB 也常失败，且错误信息不直观：
-
ERROR 1171: Primary key must not contain NULL values：MyISAM 允许主键字段为NULL，InnoDB 不允许；需先UPDATE t SET id = COALESCE(id, UUID_SHORT()) WHERE id IS NULL再改约束 - 全文索引字段的最小词长不一致：
innodb_ft_min_token_size默认是 3，而 MyISAM 的ft_min_word_len可能是 2；转换后搜索结果突变，但不会报错 - 大表转换时磁盘爆满：MySQL 5.7 默认用
COPY算法，会在tmpdir生成完整副本；8.0+ 可加ALGORITHM=INPLACE, LOCK=NONE避免锁表，但前提是无外键、无全文索引等限制
XA RECOVER 查不到 prepared 事务？先排除 MyISAM 干扰
执行 XA RECOVER 返回空结果，不代表没 XA 事务卡住。MyISAM 表会让整个 XA 流程在 PREPARE 前就终止，根本不会落日志：
- 查
INFORMATION_SCHEMA.INNODB_TRX中状态为'PREPARED'的记录：SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'PREPARED'; - 若为空，再运行
SHOW ENGINE INNODB STATUS\G，搜TRANSACTIONS段落里有没有state: prepared - 如果两者都空，基本可断定：XA 事务压根没走到 prepare 阶段——极大概率是因为某张参与表是 MyISAM，或者 binlog_format=STATEMENT + 非确定函数（如
NOW()）导致静默失败
切完 InnoDB 后 XA 还不生效？检查这三个硬性前提
引擎改对了，XA START 却仍报错或无效，问题往往不在 SQL 本身：
-
innodb_support_xa参数：MySQL 5.7 默认开启，8.0.27+ 已移除该参数，XA 功能内置启用；但若你用的是 8.0.30+，官方已标记XA为 deprecated，部分部署可能默认禁用 - 连接必须显式开启 XA 支持：JDBC URL 要带
useXa=true（如 MySQL Connector/J 8.0.33+），旧驱动或 HikariCP 默认不识别 XA 连接，得换 Atomikos 或 Bitronix - 不能混用
BEGIN和XA语句：在一个连接里先BEGIN，再执行XA START，必然触发ERROR 1399 (XAE04): XAER_RMFAIL
真正棘手的不是“怎么让 XA 跑起来”，而是“XA PREPARED 状态卡住后如何安全清理”。MySQL 不会自动推进、不跨主从同步、不保证崩溃后一致性——这些不是边缘 case，而是设计事实。一旦线上出现残留 XA 事务，XA COMMIT 或 XA ROLLBACK 必须人工核对 xid 后执行，且得确认 binlog 和 redo log 是否对齐，否则主从分裂就在一瞬间。
