innodb_support_xa 在 mysql 8.0.13+ 已彻底删除，xa 事务默认启用；关键配置是 binlog_format=row/mixed、sync_binlog=1 和 innodb_flush_log_at_trx_commit=1；必须显式执行 xa prepare 才进入两阶段提交。
MySQL 8.0+ 中 innodb_support_xa 已被移除，配置分布式事务不能靠它
直接说结论：innodb_support_xa 在 MySQL 5.7.23+ 被标记为废弃，8.0.13+ 彻底删除。试图通过设置它来“开启 XA 支持”不仅无效，还会在启动时报错 Unknown variable 'innodb_support_xa'。MySQL 的 XA 事务能力（即 XA START/END/prepare/commit/rollback）默认始终启用，只要存储引擎支持（InnoDB 就支持），无需任何开关。
真正影响分布式事务可用性的关键配置是 binlog_format 和 sync_binlog
XA 事务要参与两阶段提交（2PC），必须与二进制日志协同工作。MySQL 内部使用“XA + binlog”混合模式完成崩溃恢复一致性——这意味着 binlog 必须记录 XA 事务的 prepare 和 commit 阶段。若配置不当，主从同步或崩溃后可能丢失已 prepare 但未 commit 的 XA 分支，导致数据不一致。
-
binlog_format必须设为ROW或MIXED（STATEMENT不安全，无法准确记录 XA 分支状态） -
sync_binlog = 1：确保每个事务的 binlog 都落盘，避免 crash 后 binlog 缺失导致 XA 恢复失败 -
innodb_flush_log_at_trx_commit = 1：保证 redo log 同步写入，与 binlog 形成强一致的持久化配对
应用端调用 XA 事务时，必须显式执行 XA PREPARE，否则无法进入 2PC 流程
常见误区是以为执行 XA START + SQL + XA COMMIT 就算分布式事务。实际上，MySQL 的 XA 实现严格遵循两阶段语义：XA COMMIT 只有在事务已 XA PREPARE 后才触发第二阶段；否则它等价于本地单机提交，不提供跨节点原子性保障。
正确流程示例：
XA START 'xid1'; INSERT INTO t1 VALUES (1); XA END 'xid1'; XA PREPARE 'xid1'; -- 这一步不可省略，是 2PC 的分水岭 -- 此时事务进入 prepared 状态，可被崩溃恢复识别 XA COMMIT 'xid1';
漏掉 XA PREPARE，整个操作就只是个普通 InnoDB 事务，跟分布式无关。
XA 事务在 MySQL 中不支持自动恢复跨会话的 prepared 状态，需人工干预或外部协调器
MySQL 崩溃重启后，会自动回滚未 XA COMMIT 也未 XA ROLLBACK 的 prepared XA 事务——但前提是它能从 binlog 中读到该 XA 的 XA PREPARE 记录。如果 binlog 被清理、损坏或 sync_binlog 关闭，prepared 状态就会丢失，数据库无法判断该事务该提交还是回滚。
- 没有内置的“XA 事务协调器”，MySQL 不保存 prepared XA 的元数据到系统表中
- DBA 需定期执行
XA RECOVER查看残留的 prepared XA，并结合业务日志决定是XA COMMIT还是XA ROLLBACK - 生产环境强烈建议使用 Seata、Atomikos 等外部事务协调器，而非直连 MySQL 的原生 XA
真正麻烦的从来不是参数怎么设，而是 prepared 状态卡住后没人知道它属于哪个微服务、哪次下单请求。
