微服务跨库更新禁用XA协议，因其超时多、锁久、单点故障且状态易不一致；应改用本地消息表实现最终一致性，并按高频耦合度判断是否合并数据库。
微服务间跨库更新为什么不能直接用 XA
MySQL 的 XAXA 协议在分布式事务里看着标准，但实际一上生产就卡住：超时多、锁持有时间长、Coordinator 单点故障风险高。尤其当两个微服务分别连不同 MySQL 实例（甚至不同版本），XA RECOVER 可能查不到挂起事务，XA COMMIT 一半成功一半失败后状态不一致，人工修复成本极高。
实操建议：
- 禁用跨服务的
XA START/XA END流程，哪怕业务逻辑看起来“必须原子” - 如果旧系统已用
XA，先确认所有参与节点都开启innodb_support_xa=ON（MySQL 8.0.23+ 默认关闭） - 监控
INFORMATION_SCHEMA.XA_TRANSACTIONS表，一旦发现非空，立刻人工介入——它不会自动清理
用本地消息表替代两阶段提交
核心思路是：把“跨库一致性”拆成“本地事务 + 异步补偿”，靠消息表落盘保证不丢，再由独立消费者投递到下游服务。比 XA 好在可控、可重试、无全局锁。
实操建议：
- 消息表必须和业务表同库同事务，插入消息记录和更新业务状态写在同一个
BEGIN...COMMIT里 - 字段至少包含：
id、topic（如"order_paid"）、payload（JSON）、status（"pending"/"sent"/"failed"）、next_retry_at - 消费者轮询时用
SELECT ... FOR UPDATE SKIP LOCKED避免重复消费，更新status后再发 MQ；失败则按指数退避更新next_retry_at
什么时候该合并数据库，而不是硬扛跨库
判断依据不是“服务拆得够不够细”，而是“数据变更是否高频耦合”。比如订单服务和库存服务，只要下单、扣减、回滚发生在同一业务路径，且每秒并发超 500，强行分库只会让最终一致性窗口拉长、补偿逻辑爆炸。
实操建议：
- 检查慢查询日志里是否频繁出现跨库 JOIN 或子查询引用其他服务的表别名——这是边界错位的信号
- 如果两个服务共享同一套分库分表规则（如都按
user_idhash），且物理实例相同，优先考虑逻辑 schema 分离而非物理隔离 - 合并前确认 binlog 格式为
ROW，否则基于 GTID 的主从同步可能因 DDL 不兼容中断
Seata 或 ShardingSphere-Transaction 能直接用吗
能接入，但默认配置大概率踩坑。比如 Seata AT 模式要求所有 SQL 必须走代理，而很多微服务用 MyBatis 动态 SQL 或原生 JDBC 拼接，UPDATE 语句没带主键条件就会导致回滚失败；ShardingSphere 的 XAShardingTransactionManager 在跨分片 UPDATE 时，会把单条 SQL 拆成多个 XA 分支，放大前面说的所有 XA 缺陷。
实操建议：
- 上线前用真实流量压测
global_table中的branch_table写入延迟，超过 200ms 就要调低maxCommitRetryTimeout - 禁用
Seata的自动代理扫描，改用显式@GlobalTransactional注解，只包住真正需要强一致的最小代码块 - 如果用了
ShardingSphere，关掉transaction-type: XA，改用BASE模式 + 自定义CompensateTransaction
边界的模糊性往往藏在“读场景”里：你以为只是查个订单详情，结果接口里顺手 JOIN 了用户积分表——这时候数据库拆分策略再漂亮也没用。得盯着每个 SQL 的执行计划，而不是架构图上的虚线框。
