MySQL本地事务无法保证跨库操作原子性，因START TRANSACTION仅作用于单库；XA事务虽理论可行但已弃用且落地困难；推荐采用本地消息表、Saga或TCC等最终一致性方案，并辅以重试与对账机制。
MySQL本地事务无法保证跨库操作的原子性
单个 MySQL 实例内的 START TRANSACTION 只能锁住本库本实例里的表，一旦涉及多个数据库（哪怕在同一台物理机）、或分库分表场景下的不同 db1 和 db2，事务就断了。你执行完 INSERT INTO db1.orders，再执行 UPDATE db2.inventory，中间出错，前一条根本回滚不了。
常见错误现象：ERROR 1399 (XAE05): XAER_RMFAIL: The command cannot be executed when global transaction is in the IDLE state —— 这其实是想用 XA 却没配好，不是本地事务能解决的问题。
- 使用场景：电商下单要扣库存 + 写订单 + 更新用户积分，三者分布在不同库
- 参数差异：
BEGIN/COMMIT对跨库无效；XA START要求所有参与库都开启innodb_support_xa=ON（MySQL 8.0.30+ 已默认关闭） - 性能影响：本地事务毫秒级；XA 两阶段提交会引入额外网络往返和锁等待，吞吐直接掉 30%~50%
XA事务在MySQL中实际落地困难重重
理论上 XA COMMIT 能协调多个 MySQL 实例，但生产环境几乎没人靠它实现强一致性——不是语法不会写，而是容错和运维太脆弱。
容易踩的坑：
-
XA RECOVER查到PREPARED状态事务后，若主库宕机又恢复，可能卡在 prepare 阶段不自动推进，需要人工介入 - 从库不参与 XA 协调，只同步 binlog；如果主库 crash 后用从库升主，prepare 状态事务丢失，数据不一致
- MySQL 官方明确标注：
XA is deprecated as of MySQL 8.0.30，后续版本可能移除 - 连接池（如 HikariCP）默认不支持 XA 连接，需换用
Atomikos或Bitronix，配置复杂度陡增
替代方案选型：TCC、Saga、本地消息表，怎么选
没有银弹，选哪个取决于业务容忍度和团队能力。
关键判断点：
- 如果要求最终一致、允许几秒到几分钟延迟：用
本地消息表最轻量——在业务库建一张outbox表，和主业务操作同事务写入，再由独立消费者投递到 MQ - 如果流程长、补偿逻辑复杂（比如“预约→支付→发券→通知”），且每步都有明确的 cancel 接口：优先考虑
Saga模式，用状态机驱动，避免跨服务事务耦合 - 如果对一致性极其敏感、愿意为强一致多写大量补偿代码：
TCC更可控，但Try阶段必须预留资源，Confirm/Cancel必须幂等，开发成本高 - 注意：所有这些方案都依赖
binlog或redo log的可靠性，务必确认sync_binlog=1和innodb_flush_log_at_trx_commit=1
本地事务 + 重试 + 对账，是多数团队的真实解法
真正跑得稳的系统，往往不是靠某一个分布式事务框架，而是组合拳：用本地事务保底，靠异步重试兜底，最后用定时对账找漏。
实操建议：
- 所有核心写操作，先落
task_log表（含 status、payload、next_retry_at），和业务更新同事务 - 独立 worker 扫描
next_retry_at 的任务，最多重试 3 次，超时标记为failed - 每日凌晨跑对账脚本，比对
orders和inventory的数量/金额差，生成人工干预工单 - 不要省略
SELECT ... FOR UPDATE在关键路径上的使用——它虽不能跨库，但在单库内防止并发覆盖，是原子性的第一道防线
最常被忽略的一点：分布式场景下，“原子性”本身是个伪需求。真正要保的，是业务语义上的“结果正确”，而不是技术层面的“全部成功或全部失败”。这个认知偏差，会让很多团队在 XA 和 TCC 上浪费数月却收效甚微。
