mysql默认max_prepared_transactions=0禁用xa事务，必须在my.cnf中显式设为≥32（建议峰值并发1.5倍），重启生效；innodb_support_xa已废弃，innodb始终支持xa；表须为innodb引擎，repeatable-read隔离级别即可；执行xa recover需显式授予xa_recover_admin权限。
max_prepared_transactions 必须显式调大
MySQL 默认的 max_prepared_transactions=0，意味着禁用 XA 事务准备状态持久化 —— 这会导致 XA PREPARE 失败并报错 ERROR 1399 (XAE09): XAER_RMFAIL: The command cannot be executed when global transaction is in the IDLE state 或直接拒绝执行。
- 必须在
my.cnf（Linux）或my.ini（Windows）的[mysqld]段中显式设置，例如：max_prepared_transactions=128 - 该值应 ≥ 预期并发 XA 事务数（含悬挂事务），建议按峰值并发的 1.5 倍预估，最小不低于 32
- 修改后必须重启 MySQL 生效，
SET GLOBAL动态修改无效
innodb_support_xa 已废弃，无需配置
MySQL 5.7.10+ 中 innodb_support_xa 系统变量已被移除，InnoDB 始终启用 XA 支持 —— 只要使用 InnoDB 表且满足其他条件，XA START 就能正常工作。
- 若在旧版本（如 5.6）中看到该参数，设为
ON即可；但 5.7.10 及以后版本再设会报错Unknown system variable 'innodb_support_xa' - 验证方式不是查变量，而是执行
SHOW ENGINES，确认InnoDB行的XA列为YES - 表必须是 InnoDB 引擎，MyISAM 或 Memory 引擎执行
XA START会静默失败或报错XAER_NOTA
transaction-isolation 要设为 SERIALIZABLE？不，REPEATABLE-READ 即可
文档里常提“XA 需串行化隔离级别”，这是误解。MySQL XA 事务实际依赖的是 InnoDB 的行锁与 prepare 日志机制，而非会话级隔离级别。
-
transaction-isolation=REPEATABLE-READ（默认）完全支持 XA，无需改成SERIALIZABLE - 改成
SERIALIZABLE反而可能因间隙锁加剧阻塞，降低并发度 - 真正影响 XA 行为的是：是否开启 binlog（
log_bin=ON）、是否启用innodb_flush_log_at_trx_commit=1（保证 prepare 日志落盘）
XA RECOVER 权限容易被忽略
执行 XA RECOVER 查看悬挂事务时，普通账号常报错：ERROR 1401 (XAE03): XAER_RMERR: fatal error occurred...，本质是权限不足。
- 需单独授予
XA_RECOVER_ADMIN权限（MySQL 8.0.29+）或旧版的PROCESS权限 - 授权命令：
GRANT XA_RECOVER_ADMIN ON *.* TO 'user'@'host'; - 注意：该权限不能通过
GRANT ALL自动包含，必须显式赋予
XA 的核心约束不在配置项数量，而在 prepare 状态必须能被持久化且可被跨会话查询 —— 所以 max_prepared_transactions 和 XA_RECOVER_ADMIN 是唯二绕不开的硬门槛。其他所谓“必须配置”多是过时文档遗留的误导。
