mysql原生事务无法保证跨库最终一致，因其begin/commit仅作用于单实例，跨库需依赖应用层+外部组件（如binlog+mq）实现异步补偿；xa协议虽支持强一致但运维复杂、故障恢复不可靠，故生产环境多采用本地事务+消息队列的最终一致性方案。
MySQL 本身不支持跨库（尤其是跨实例）的最终一致性，所谓“最终一致”不是它自己达成的，而是靠应用层设计 + 外部组件协同实现的妥协方案。直接在 SQL 层写 BEGIN/COMMIT 对跨库操作完全无效。
为什么不能用 MySQL 原生事务保证跨库最终一致
单机 MySQL 的 BEGIN/COMMIT 只作用于当前连接所连的实例；哪怕两个库在同一个 MySQL 进程下（db_a 和 db_b），也仅当显式使用 XA START 等命令、且客户端/中间件完整实现两阶段提交逻辑时，才可能勉强维持强一致——但代价是锁持有时间长、故障恢复不可靠、运维极难。而“最终一致”恰恰要避开这种高风险路径：
-
XA PREPARE后若协调器宕机，事务会卡在PREPARED状态，持续占用行锁和连接，MySQL 不会自动清理 -
XA RECOVER返回的xid没有业务上下文，无法判断该commit还是rollback，人工干预极易出错 - 跨实例场景下，MySQL 不提供全局事务 ID 分发、状态持久化、失败重试等能力，这些都得自己补
-
binlog_format=STATEMENT时，NOW()、UUID()等函数在从库回放结果不同，下游消费binlog做同步就会逻辑错乱
基于 binlog + 消息队列的轻量落地方式
这是目前线上最常用、故障率最低的最终一致性方案，核心是把“业务变更”作为事实源头，通过解析 binlog 触发异步补偿，而非试图让多个库同步提交：
- 业务库执行本地事务（如扣减库存），成功后立即提交，不等待其他库
- 部署
canal或maxwell监听该库binlog，过滤出目标表的UPDATE/INSERT事件 - 将事件封装成消息，发往
Kafka，并确保发送与本地事务绑定（可用本地消息表 + 定时扫描） - 下游服务订阅消息，执行对应操作（如更新账单库），必须实现幂等：用
UNIQUE KEY冲突忽略、或先SELECT FOR UPDATE判断是否已处理 - 消息消费失败时，靠 MQ 重试 + 死信队列告警，避免无限堆积
Seata AT 模式接入时最容易漏掉的三件事
Seata 不是开箱即用的“魔法开关”，配错任意一项，整个分布式事务就退化为多个孤立本地事务：
- 每个物理库（不是逻辑库）都必须手动建
undo_log表，字段名大小写、索引结构必须和 Seata 官方 DDL 完全一致，少一个branch_id索引就会 fallback -
seata-server的store.mode必须设为db并配置可用数据库，否则分支注册状态丢失，崩溃后无法恢复 - 应用端数据源必须被 Seata 的
DataSourceProxy包装，且@GlobalTransactional注解需落在真正发起 DB 操作的方法上，否则事务不生效
最容易被忽略的是：binlog 格式、隔离级别、以及事务边界是否真的覆盖了所有相关操作。很多“不一致”问题其实源于 autocommit 意外开启、隐式提交语句（如 ALTER TABLE）、或框架 @Transactional 默认只对运行时异常回滚。最终一致性不是靠加锁堆复杂度，而是靠准确定义边界、控制并发粒度、以及接受某些场景下必须用异步补偿来换可用性。
