MySQL原生不支持跨库两阶段提交，无法保证分库分表下事务的ACID；需借助XA（极少启用）、Seata/TCC、Saga或消息队列等方案实现最终一致性或强一致性，但各有性能、复杂度与运维成本权衡。
跨库事务为什么在MySQL分库分表中难以保证ACID
因为MySQL原生不支持跨库的两阶段提交（2PC）协调器，也没有内置的分布式事务管理服务。一旦事务涉及多个物理数据库实例，COMMIT 或 ROLLBACK 就无法原子性地同步生效——某个库成功提交了，另一个库可能因网络抖动、超时或宕机而回滚失败，直接破坏一致性。
MySQL单机事务机制与跨库场景的根本冲突
MySQL的事务依赖本地 redo log 和 binlog 协同，靠 XA START/END/prepare/commit 实现有限的 XA 事务能力，但生产环境极少启用，原因包括：
-
XA要求所有参与节点都开启innodb_support_xa=ON（5.7+ 默认关闭），且需手动配置binlog_format=ROW - XA 事务会显著拖慢吞吐：prepare 阶段锁资源时间更长，协调器单点故障会导致事务长期处于
PREPARED状态，需要 DBA 手动介入清理 - 主流中间件（如 ShardingSphere、MyCat）默认不透传 XA，多数业务代码也从未处理过
XID恢复逻辑
实际业务中“看似跨库”却能规避事务的常见做法
不是所有多库写入都必须强一致。很多所谓“跨库事务”，本质是业务流程编排，而非数据库级原子操作：
- 用
消息队列替代UPDATE user_db.users SET status=1+INSERT order_db.orders的同步调用：先本地落库，再发order_created消息，下游消费后更新状态 - 将“用户扣余额”和“创建订单”拆成两个幂等接口，前端或网关层控制执行顺序，失败时走补偿（如定时任务查
user_balance_log补单） - 对时效性要求低的操作（如统计类写入），直接异步写入
stat_db，接受分钟级延迟，彻底绕开事务
Seata/TCC 这类方案真能解决跨库事务吗
能，但代价明确：它把事务协调逻辑从数据库下移到应用层，要求你为每个业务操作显式编写 try/confirm/cancel 方法。这意味着：
- 每个跨库写入点都要改造，
update_inventory接口得配套confirm_inventory和cancel_inventory - 所有参与方必须支持幂等和可重试，否则
confirm失败后无法自动兜底 - 一旦
TC（Transaction Coordinator）宕机，未完成事务会卡住，依赖人工干预或超时自动cancel，仍有数据不一致窗口
真正上线后你会发现，80% 的“必须强一致”需求，其实只是没想清楚最终一致的边界在哪里——比如支付成功后订单状态允许 3 秒内不同步，但不能丢失；这种场景下，消息 + 对账远比 TCC 更轻量、更可控。
