MySQL 存储引擎本身不支持分布式事务
MySQL 的
InnoDB引擎只提供本地 ACID 事务，无法跨 MySQL 实例协调提交或回滚。所谓“用存储引擎做分布式事务”是常见误解——
MyISAM、
Memory等更不支持事务；
InnoDB的
XA START仅限单实例内多分支 XA，且需手动管理，实际极少用于生产级分布式事务。
真正可行的方案是靠外部协调器 + InnoDB 配合
MySQL 参与分布式事务，必须依赖外部 XA 协调器（如 Seata、Atomikos、XA-compliant application server），由它控制各参与方的 prepare/commit/rollback 流程，InnoDB 仅作为 XA resource provider 响应指令。
START TRANSACTION不够，必须用
XA START 'xid'显式开启 XA 事务 每个分支需唯一
xid（格式为
gtrid,bqual,formatID），协调器负责生成和分发
InnoDB要求
innodb_support_xa=ON（MySQL 5.7 默认开启，8.0.27+ 已移除该参数，XA 功能内置启用） 应用层不能混用
BEGIN和
XA语句，否则会报错
ERROR 1399 (XAE04): XAER_RMFAIL
XA COMMIT 失败时数据可能处于 PREPARED 状态
这是最易被忽略的风险点：若协调器在
XA PREPARE后崩溃，MySQL 中事务卡在
PREPARED状态，既不提交也不回滚，长期占用锁和 undo log，影响备份与 purge。 可用
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'PREPARED';查看残留 XA 事务 人工恢复需先
XA RECOVER获取 xid 列表，再执行
XA COMMIT 'xid'或
XA ROLLBACK 'xid'MySQL 重启后不会自动清理 PREPARED 状态，必须人工介入或依赖协调器重试机制
XA START 'gaia-001'; INSERT INTO orders VALUES (1001, 'alice', 299.9); XA END 'gaia-001'; XA PREPARE 'gaia-001'; -- 此时若协调器宕机，该 XA 事务将滞留
生产环境更推荐非 XA 方案替代
XA 协议性能开销大（额外 round-trip、prepare 阶段写盘）、运维复杂、故障恢复难。多数场景下应优先考虑：
基于消息队列的最终一致性（如 MySQL binlog + Kafka + 消费端幂等写入） TCC 模式（Try/
Confirm/
Cancel接口由业务实现） SAGA 模式（长事务拆解为可补偿子事务） 如果必须强一致且跨库，直接用 TiDB 或 OceanBase 这类原生分布式数据库，而非在 MySQL 上硬套 XA
真正卡住人的不是语法，而是 PREPARED 状态没人收尾、协调器单点故障后事务不可逆、以及开发误把
START TRANSACTION当成 XA 使用。
