MySQL不支持跨库/跨实例分布式事务一致性，因其缺乏内置XA协调器，需应用层通过补偿、重试、状态管理等手段实现最终一致。
MySQL 本身不支持跨库/跨实例的分布式事务一致性
单机 MySQL 的 START TRANSACTION 只能保证本实例内 ACID，一旦涉及多个 MySQL 实例（比如分库分表、读写分离、微服务各自持库），COMMIT 和 ROLLBACK 就失效了。这不是配置问题，是架构层面的限制——MySQL 没有内置的 XA 全局事务协调器，更不参与外部分布式事务协议（如 Seata 的 AT 模式、Saga）。
真要跨 MySQL 实例做一致性，得靠应用层补足
常见做法不是“让 MySQL 支持”，而是绕开它，在业务代码里把事务拆成可补偿、可重试、有明确状态的步骤：
-
INSERT INTO order_db.orders成功后，发 MQ 消息触发inventory_db.deduct_stock，失败则走本地补偿任务查 MQ 状态+重试 - 用
SELECT ... FOR UPDATE锁住关键行，但只限同库同表；跨库锁无效，且容易引发死锁或长事务阻塞 - 避免在事务中调用 HTTP 接口或远程 RPC，网络超时会导致
UNDO LOG无法回滚，留下悬挂事务 - 如果必须用 XA（比如老系统强依赖），MySQL 虽支持
XA START/XA COMMIT，但性能差、故障恢复复杂，且要求所有参与节点都开启innodb_support_xa=ON（8.0.30+ 已默认关闭）
分库分表场景下，“事务”本质是妥协后的状态对齐
ShardingSphere、MyCat 这类中间件提供的“分布式事务”功能，底层仍是两阶段提交（2PC）或 TCC 补偿，不是 MySQL 自己完成的。实际落地时要注意：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 中间件的
transactionType配置为BASE（即 Saga）还是XA，直接影响日志表是否要建在每个物理库中 -
sharding-jdbc的SeataATShardingTransactionManager要求每个分片库都有undo_log表，缺一个就整个事务 fallback 到本地事务，丢失一致性 - 跨分片的
JOIN查询天然不一致：A 分片已提交，B 分片还在 prepare，此时读请求可能看到脏数据——只能靠最终一致性 + 版本号/时间戳过滤
最容易被忽略的其实是隔离级别和 binlog 格式
即使单库事务正确，复制链路也可能破坏一致性：
- 主库用
READ-COMMITTED，从库用REPEATABLE-READ，会导致主从之间幻读表现不一致，下游消费 binlog 做同步时逻辑错乱 -
binlog_format=STATEMENT在涉及NOW()、UUID()、自增主键等非确定性函数时，从库回放结果与主库不同 - GTID 开启后，
SET sql_log_bin=0跳过写 binlog 的操作，会破坏 GTID 一致性，导致后续 failover 失败
分布式系统里，MySQL 往往只是状态快照的落点，不是事务仲裁者。真正难的不是写 SQL，是定义清楚“什么算一致”——是强一致？最终一致？还是业务可接受的窗口期不一致？这个判断比选哪个框架更重要。
