MySQL不支持跨数据库事务一致性，因事务由存储引擎（如InnoDB）管理，各库表属独立事务上下文，BEGIN/COMMIT仅作用于默认库；显式跨库更新无法原子提交，失败时已提交部分不可回滚。
MySQL 本身不支持跨数据库事务的一致性提交——哪怕两个库都在同一台 MySQL 实例上，BEGIN/COMMIT 也只对当前连接默认数据库（USE db_name 指定的）生效，无法原子性地控制另一个库的修改。
为什么跨库事务在 MySQL 中不可行
MySQL 的事务管理基于存储引擎层（如 InnoDB），而每个库的表都属于独立的表空间和事务上下文。即使你显式写 UPDATE db1.orders SET status = 'paid' WHERE id = 1 和 UPDATE db2.logistics SET status = 'dispatched' WHERE order_id = 1 在同一个 BEGIN 块里，只要它们操作的是不同库下的表，InnoDB 会为每条语句单独开启/提交隐式事务（尤其当 autocommit=1 时），根本无法保证“全成功或全失败”。
常见错误现象：db1.orders 更新成功，db2.logistics 因外键或字段长度超限失败，但前者已提交，无法回滚。
- MySQL 官方文档明确说明：事务不能跨越多个存储引擎（哪怕同是 InnoDB），更不支持跨库原子提交
-
XA TRANSACTION理论上可协调多资源，但 MySQL 对 XA 支持极弱（仅限单实例内有限场景），且生产环境禁用——它不支持 DDL、不兼容 GTID、主从复制中极易卡住 - 试图用存储过程封装两库操作 +
DECLARE HANDLER捕获错误，只能做到“发现失败后手动补救”，不是真正的事务一致性
替代方案：用应用层事务 + 补偿逻辑兜底
真正能落地的方案，是把“跨库一致性”拆解为“本地事务 + 业务补偿”。核心思路是：先在一个库完成主操作并记录状态，再异步触发另一库动作；失败时靠幂等+重试+反向操作修复。
- 第一步：在
db1执行核心变更（如扣库存），同时插入一条outbox表记录（outbox必须和业务表同库同事务），字段含目标库操作类型、参数 JSON、状态pending - 第二步：用独立消费者（如 Go worker 或定时任务）轮询
db1.outbox，状态为pending的记录，调用接口或直接执行db2的 SQL；成功则更新outbox.status = 'done' - 第三步：若
db2失败，记录错误并设status = 'failed'；后续按策略重试（带指数退避），或人工介入执行补偿 SQL（如UPDATE db1.inventory SET stock = stock + 1 WHERE order_id = ?） - 所有
db2操作必须幂等：INSERT ... ON DUPLICATE KEY UPDATE，或先SELECT判重再处理
SQL Server 的情况略有不同，但依然不推荐依赖
SQL Server 支持跨库事务（因底层使用 MSDTC 协调），语法上可以写 BEGIN DISTRIBUTED TRANSACTION，但实际生产中几乎不用：
- MSDTC 配置复杂，Windows 域环境才稳定，Linux 版 SQL Server 不支持
- 一旦任一库网络抖动或超时，整个事务卡死，
innodb_lock_wait_timeout类机制失效 - 高并发下性能断崖式下跌，监控困难，错误码晦涩（如
XACT_ABORT触发后难以定位源头） - 云环境（如 Azure SQL）默认禁用分布式事务，需额外开通且计费
最容易被忽略的点：别让“看起来像事务”的代码骗过自己
很多团队在存储过程中写类似这样的逻辑：
START TRANSACTION; UPDATE db1.accounts SET balance = balance - 100 WHERE id = 1; UPDATE db2.audit_log SET status = 'charged' WHERE ref_id = 1; IF @@ERROR != 0 THEN ROLLBACK; ELSE COMMIT; END IF;
这看似完整，但 @@ERROR 只捕获上一条语句的错误，且 UPDATE db2.audit_log 实际已脱离当前事务上下文自动提交。真正运行时，第一句成功、第二句失败，ROLLBACK 只能撤掉第一句——而第一句早已落盘。这种伪事务比不加事务更危险，因为它给了错误的安全感。
