sql触发器无法参与xa分布式事务，因其运行于本地事务上下文，不能注册为xa资源；触发器内远程操作脱离xa协调，导致回滚不一致、死锁及隔离级别陷阱，应改用应用层xa控制或本地消息表+补偿服务。
触发器无法注册为XA资源，天然脱离分布式事务协调
SQL触发器运行在数据库本地事务上下文中，而XA分布式事务要求所有参与者（如远程库、消息队列）必须显式注册为XA resource，并由外部协调者（如JTA Transaction Manager）统一调度。触发器内部调用dblink、INSERT INTO remote_table或执行远程DML时，这些操作属于独立会话，数据库不会将其上报给XA协调者——它只是本地事务中一段PL/pgSQL或T-SQL逻辑。
常见错误现象：
- 主库开启XA事务 → INSERT触发器 → 触发器内用
dblink向从库写数据 → XA第二阶段rollback → 本地表变更被撤销，但dblink已提交的远程操作无法撤回 - 触发器内
SELECT FOR UPDATE锁远程行 → 跨库死锁 → XA协调者完全无法感知或介入解锁
触发器内嵌套事务会破坏XA语义和隔离级别
即使强行在触发器里调用扩展函数（如PostgreSQL的pg_xact_commit()），也会触发隐式隔离降级：外层XA事务可能是SERIALIZABLE，而触发器新开的子事务默认使用READ COMMITTED；触发器读取的OLD/NEW值可能已过期，因并发修改未被外层事务锁定。
这不会报错，但会导致校验失效——比如订单金额校验通过，实际库存却因并发扣减超卖。PostgreSQL的AFTER ROW触发器看到的是已提交状态，而XA尚未commit，形成“幻读式不一致”。
触发器不能提交或回滚父事务，也无法感知远程结果
MySQL和PostgreSQL的触发器运行在父语句的事务上下文中。COMMIT或ROLLBACK在触发器内直接报错：ERROR 1609 (HY000): Transaction is not allowed in stored function or trigger。更危险的是，你可能在AFTER INSERT触发器里往Kafka发消息，但Kafka不可用——触发器不会抛异常（除非你显式SIGNAL），主事务照常提交，数据“看起来成功了”，实际下游根本没收到。
根本原因在于：触发器没有网络I/O能力，“发消息”本质是往本地表写记录或调用UDF（极不推荐）。真正发消息的动作必须由应用层或独立消费者完成，且要带重试、死信、幂等key。
替代方案必须把控制权交还应用层或异步服务
可行路径只有两条：
- 应用代码中开启XA事务（如Java的
UserTransaction.begin()），先执行本地表变更，再通过支持XA的连接池（如PostgreSQL的xa_datasource）执行远程更新，所有操作完成后统一commit/rollback - 触发器只往本地
tx_outbox表插入一条记录（含event_type、payload、status='pending'），后续由独立的XA-aware轮询服务消费并发起跨库操作——这才是可观察、可重试、可补偿的模式
最容易被忽略的是：tx_outbox.status字段绝不能由触发器改写，必须由外部服务更新；且日志表里避免存大字段（如TEXT或长JSON），否则影响轮询性能和binlog体积。
