MySQL存储过程不支持跨库两阶段提交，仅能控制单库事务；真正2PC需应用层通过XA命令或事务管理器协调，存储过程只能作为无事务控制的DML执行单元。
MySQL 存储过程本身不支持跨库两阶段提交
直接在 CREATE PROCEDURE 里用 START TRANSACTION + COMMIT 只能控制单个数据库实例内的事务。一旦涉及多个 MySQL 实例（比如订单库、库存库），存储过程内部的语句无法触发真正的两阶段提交（2PC）——它没有能力协调外部节点、写 prepare 日志、等待投票，更不会跟 XA 协议打交道。
常见错误现象是：开发者误以为「在存储过程中调两个 INSERT INTO db1.t1 和 INSERT INTO db2.t2，再套个 COMMIT 就算分布式事务」，结果出现部分成功、数据不一致。
- MySQL 的
XA START/XA END/XA PREPARE/XA COMMIT系列命令才是 2PC 的底层接口，但它们不能在存储过程中安全使用：MySQL 不允许在存储过程内执行XA PREPARE后再跨连接执行XA COMMIT，且存储过程无法持有多个独立连接上下文 - 即使强行用
SELECT ... INTO @var模拟状态传递，也无法规避连接隔离与事务生命周期绑定问题 - 某些 ORM 或中间件（如 Seata、ShardingSphere）会拦截 SQL 并注入 XA 流程，但这是在应用层或代理层完成的，和存储过程无关
真正可行的路径只有应用层驱动 XA 事务
两阶段提交必须由具备全局视野的协调者发起，而这个角色只能落在应用代码、事务管理器（TM）或数据库代理上。存储过程只是被调用的“执行单元”，不具备调度权。
典型可行流程如下：
- 应用代码（如 Java Spring）调用
javax.transaction.UserTransaction.begin()开启全局事务 - 通过两个独立数据源分别执行：一个连订单库，调用
CALL order_proc(...)；另一个连库存库，调用CALL stock_proc(...) - 两个调用都在各自连接上隐式参与 XA：JDBC 驱动自动将
INSERT等操作纳入当前 XA 分支，并在prepare阶段刷 redo/undo 日志 - 应用层最后调用
commit()，触发 TM 向所有 RM 发送XA PREPARE→ 收集投票 →XA COMMIT或XA ROLLBACK
注意：order_proc 和 stock_proc 本身仍需保持“无事务控制”——即不包含 START TRANSACTION 或 COMMIT，否则会干扰 XA 分支的生命周期。
如果硬要在数据库侧封装逻辑，只能用外部协调+存储过程组合
你可以把存储过程当作「本地事务执行体」，但必须剥离其事务控制权，让外部系统来统一管理两阶段流程。这要求你放弃“纯 SQL 解决方案”的幻想。
- 存储过程只做 DML 操作，不带
COMMIT/ROLLBACK，也不依赖AUTOCOMMIT=OFF的隐式事务 - 准备阶段由应用或中间件先对各库分别执行
XA START 'xid1'; CALL proc1(); XA END 'xid1'; XA PREPARE 'xid1'; - 提交阶段再统一发
XA COMMIT 'xid1'—— 这些命令必须由同一客户端连接串行执行，不能塞进存储过程里 - MySQL 的
information_schema.INNODB_TRX和performance_schema.data_locks可用于排查卡在PREPARED状态的事务，但无法靠存储过程自动恢复
容易被忽略的关键点
XA 事务不是开个开关就能用的黑盒。真实环境中最常被绕过、最终导致数据错乱的是：日志持久化顺序、协调者单点故障、以及超时后未清理的 PREPARED 事务。
MySQL 要求 innodb_flush_log_at_trx_commit=1 且 sync_binlog=1 才能保证 prepare 阶段日志落盘；否则崩溃后无法判断该提交还是回滚。而一旦协调者宕机，那些已 PREPARE 但没收到后续指令的分支，会一直锁住资源，直到 DBA 手动执行 XA RECOVER + XA COMMIT/XA ROLLBACK —— 这个动作无法自动化嵌入任何存储过程。
