mysql自带事务对跨库无效，因其start transaction和commit仅作用于单实例，多库操作无全局事务管理器，无法保证原子性。
MySQL分布式场景下，多数据源一致性无法靠单个数据库自身机制兜底，必须依赖外部协调或设计约束。强一致代价过高，生产环境普遍接受“最终一致 + 可观测 + 可修复”的组合策略。
为什么 MySQL 自带事务对跨库无效
MySQL 的 START TRANSACTION 和 COMMIT 只作用于当前连接所连的单个实例。当你操作 db0.order 和 db1.user 时，两个库各自开启独立事务，彼此无感知——没有全局事务管理器（如 XA Resource Manager），就不存在原子性保障。
常见错误现象：
- 代码里写了两个
UPDATE+ 一个COMMIT，误以为能一起提交；实际是两次独立提交，中间失败会导致状态分裂 - 用
XA START手动发起 XA 事务，但未配置innodb_support_xa=ON或未启用两阶段提交（2PC）流程，结果XA COMMIT报错ERROR 1399 (XAE04)
参数差异注意点：
-
innodb_support_xa在 MySQL 8.0.30+ 已废弃，官方明确不推荐用于生产 XA 分布式事务 - 即使启用，2PC 存在单点协调者故障、prepare 阶段挂起后阻塞资源等问题，超时策略难调，运维成本高
用 ShardingSphere 实现逻辑上的一致性写入
ShardingSphere-JDBC / Proxy 不是数据库，而是 SQL 拦截与重写的中间层。它不能让跨库事务真正原子化，但可通过“分片键绑定 + 本地事务 + 补偿”降低不一致概率。
实操建议：
- 所有涉及多库更新的业务，强制要求 SQL 中包含相同分片键（如
user_id），使路由到同一物理库，退化为单库事务 - 若必须跨库（如统计汇总写入另一库），使用 ShardingSphere 的
SeataATMode插件对接 Seata，由 Seata 代理生成 undo_log 并协调分支事务 - 避免在分片环境下直接执行
INSERT INTO db1.t1 SELECT * FROM db0.t2类语句——ShardingSphere 无法解析跨数据源查询，会抛出UnsupportedOperationException
性能影响：开启 Seata AT 模式后，每个 SQL 多一次 undo_log 写入和全局锁校验，吞吐下降约 15–30%，但比纯人工补偿更可控。
最终一致性 + 异步校验是更现实的选择
多数金融外业务（如订单+积分+优惠券）并不需要实时强一致，只要保证“几分钟内可自愈”，就能兼顾可用性与开发效率。
可落地的组合方案：
- 写操作走 Cache-Aside：先改 MySQL 主库，再发 MQ 消息触发 Redis 删除 + 跨库同步任务
- 部署定时一致性检查服务，扫描关键表的
updated_at时间戳或 binlog 位点，对比各库间记录差异，生成修复 SQL 或告警 - 对 binlog 做结构化解析（用
canal或debezium），把变更事件投递到 Kafka，下游消费者按业务规则做幂等合并写入
容易踩的坑：
- 校验脚本只查 count(*)，忽略 delete 场景 —— 应该比对 checksum 或主键集合 diff
- MQ 消费失败后没死信队列，导致同步中断无声无息；必须配
max.retries=3+dead.letter.topic - binlog_format 设为
MIXED或STATEMENT，导致 canal 解析出错或丢失更新 —— 务必设为ROW
真正棘手的不是技术选型，而是业务语义本身是否允许“中间态”。比如库存扣减必须严格串行，那就要用分布式锁 + 本地事务兜底；而用户标签更新晚几秒无关紧要，直接走异步 pipeline 更稳。别试图用一套方案覆盖所有场景。
