MySQL存储引擎不支持分布式事务，InnoDB仅提供本地ACID事务；需依赖外部XA协调器（如Seata）配合XA START/COMMIT等指令实现，且PREPARED状态需人工处理，否则长期占用资源。
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 使用。
