myisam引擎完全不支持xa分布式事务，因其引擎层缺失xa接口、事务日志和状态机，执行xa prepare必报error 1399；需通过information_schema.tables确认表引擎，批量排查myisam表，并确保binlog启用且格式非statement。
MyISAM 引擎根本不支持 XA 分布式事务——这不是配置问题，也不是版本差异，而是引擎层彻底缺失实现。只要语句涉及任意 MyISAM 表，XA PREPARE 就会立刻报错 ERROR 1399 (XAE00): XAER_RMFAIL，整个 XA 分支直接失效。
确认表是否真用 InnoDB，别信 SHOW CREATE TABLE
很多人以为建表没指定 ENGINE 就是 InnoDB，但老库或迁移库中大量存在隐式 MyISAM 表。SHOW CREATE TABLE t1 看一眼不够稳妥，因为视图、临时表、分区表子分区可能各自用不同引擎，XA START 一碰到 MyISAM 分区就崩。
- 唯一可靠方式是查元数据：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t1' - 批量检查所有 MyISAM 表：
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE ENGINE = 'MyISAM' - 特别注意：分区表每个子分区可单独指定引擎，
INFORMATION_SCHEMA.PARTITIONS才能看清真实分布
ALTER TABLE ENGINE=InnoDB 失败的常见原因
即使你决心切到 InnoDB，ALTER TABLE t ENGINE=InnoDB 也常失败，且错误信息不直观：
- MyISAM 允许主键字段为
NULL，InnoDB 不允许；需先ALTER TABLE t MODIFY pk_col INT NOT 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，部分部署可能默认禁用 -
max_prepared_transactions必须设为大于 0 的值（默认是 0），否则XA PREPARE直接拒绝 - 必须启用 binlog，且
binlog_format不能为STATEMENT（含NOW()、UUID()等非确定函数时 prepare 会静默失败）
真正麻烦的不是改引擎，而是那些没显式声明引擎的老表、被忽略的分区子表、以及 binlog_format 和非确定函数交织的静默失败场景——这些地方最容易漏查，一出问题就卡在“查不到 prepared”，却找不到源头。
