MySQL存储过程无法实现跨库事务一致性，因InnoDB事务上下文按库隔离，BEGIN/COMMIT仅作用于默认库；跨库操作实际触发隐式提交，失败后已提交部分不可回滚，唯一可行方案是应用层本地事务+outbox表+异步补偿。
MySQL 存储过程里无法实现真正的跨数据库事务一致性——BEGIN/COMMIT 对其他库的表修改完全不生效，所谓“原子提交”是假象。
为什么 MySQL 存储过程里的 BEGIN/COMMIT 对跨库操作无效
MySQL 的事务边界由存储引擎（如 InnoDB）控制，而每个数据库（schema）下的表在物理上属于独立表空间和事务上下文。即使你在 BEGIN 块里写：
UPDATE db1.orders SET status = 'shipped' WHERE id = 1; UPDATE db2.shipments SET state = 'sent' WHERE order_id = 1;
只要 db1 和 db2 是两个不同库名，InnoDB 实际会为第二条语句单独开启隐式事务（尤其当 autocommit=1 时），第一条已提交，第二条失败也无法回滚。
- 常见错误现象：
db1.orders状态变成shipped，但db2.shipments因字段超长或外键缺失报错ERROR 1452，前者已不可逆 - 别信
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION—— 它只能捕获错误，不能撤回已提交的跨库变更 -
XA START在 MySQL 中仅限单实例内极窄场景，不支持 DDL、不兼容 GTID、主从复制中极易卡死，生产环境禁用
真正能落地的替代方案：本地事务 + outbox 表 + 异步补偿
把“强一致性”降级为“最终一致性”，靠应用层逻辑兜底，这是唯一被大规模验证过的方案。
- 第一步：在主库（如
db1）事务内完成核心操作，并插入一条outbox记录（必须与业务表同库同事务）
字段至少含：target_db、target_table、operation（INSERT/UPDATE）、payload（JSON）、status（pending） - 第二步：用独立消费者（Go/Python worker 或定时任务）轮询
db1.outbox，捞出status = 'pending'的记录，执行目标库 SQL 或调用目标服务接口 - 第三步：成功则
UPDATE db1.outbox SET status = 'done'；失败则设status = 'failed'，并记录错误详情，后续按指数退避重试 - 关键约束：
outbox表必须有UNIQUE KEY (target_db, target_table, operation, payload)防重复；所有消费者需幂等处理
SQL Server 场景下可考虑链接服务器 + 触发器（但有明确限制）
SQL Server 支持跨实例事务，前提是启用 MSDTC 并配置好链接服务器，但它只适合小数据量、低频变更的少数几张表。
- 必须确保源库和目标库网络稳定，MSDTC 服务始终在线；否则触发器会阻塞源表写入，直接拖垮业务
- 一次
UPDATE影响超过 5000 行，远程写入耗时剧增，LOCK_TIMEOUT极易触发，导致源库事务长时间挂起 - 禁止双向同步：A→B 的触发器若再触发 B→A 的触发器，会陷入递归，必须用
TRIGGER_NESTLEVEL()检查并退出 - DDL 变更（如加字段）不会自动同步，触发器代码必须人工更新，漏改就导致
INSERT报错ERROR 213
跨库事务一致性最常被忽略的一点：它从来不是数据库能力问题，而是架构取舍问题。你试图用存储过程解决的，其实是分布式系统里的“Saga 模式”该管的事——把一个大事务拆成若干本地事务，靠补偿动作修复失败分支。硬要在存储过程里塞 XA 或嵌套事务，只会让问题更隐蔽、更难排查。
