数据库触发器无法直接调用远程接口，因受事务上下文限制；可行方案是CDC+应用中转或本地表队列+外部进程轮询，但均需处理幂等性、事务一致性及错误补偿。
触发器里不能直接调用远程接口
MySQL、PostgreSQL 等主流 SQL 数据库的触发器（TRIGGER）运行在服务端事务上下文中，不支持发起 HTTP 请求、执行 shell 命令或连接外部数据库——这是硬性限制，不是配置问题。你看到的“触发器调用远程 API”基本是混淆了概念：实际是应用层监听 binlog / WAL / CDC 流，再主动发请求。
常见错误现象：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA（定义函数时未声明特性），或触发器内写 curl、http_call() 直接报语法错。
- MySQL 触发器只允许操作本库表（
INSERT/UPDATE/DELETE）、设置变量、调用内置函数（如NOW()、UUID()） - PostgreSQL 的
PL/pgSQL触发器同样禁止pg_notify()以外的网络 I/O；想发 HTTP？得靠plproxy或外部 daemon 配合 - 哪怕用
sys_exec()（MySQL UDF）或dblink_exec()（PostgreSQL），也需额外安装、提权，且严重破坏事务一致性
真正可行的同步路径：CDC + 应用中转
想让 A 库变更自动推到 B 库，核心是把“触发时机”和“远程动作”解耦：数据库只负责生成变更日志（CDC），由独立服务消费并投递。这不是妥协，而是唯一稳定方案。
使用场景：跨机房主从弱一致同步、微服务间数据冗余、数仓实时入湖。
- MySQL 推荐用
canal（阿里开源）或maxwell消费 binlog，解析成 JSON 后发 Kafka / HTTP 到目标服务 - PostgreSQL 用
logical replication+pgoutput协议，或wal2json插件输出变更流 - 目标服务收到消息后，用标准 DB 驱动写入 B 库；注意幂等处理（比如用
upsert+ON CONFLICT或REPLACE INTO）
如果坚持用触发器，只能走“本地表中转”
在同一个数据库实例内建一张 sync_queue 表，触发器只往里插记录；再起一个常驻进程（如 Python 脚本）轮询该表，取到就调用远程 API 或直连 B 库执行 SQL。这绕开了触发器限制，但引入新问题。
参数差异与风险点：
-
sync_queue必须有自增 ID 和status字段（'pending'/'done'/'failed'），否则重复消费或丢失 - 轮询间隔不能太短（避免 DB 压力），也不能太长（延迟高）；建议用
SLEEP(0.1)+SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+）防并发冲突 - 远程调用失败时，必须更新
status = 'failed'并记录error_message，否则这条记录永远卡住
别忽略事务边界和最终一致性
无论走 CDC 还是本地队列，A 库事务提交和 B 库写入永远不在同一事务中。这意味着：A 成功、B 失败 → 数据不一致；B 成功、A 回滚 → B 多出脏数据。
能做的只有降低风险：
- 在 A 库变更前，先查 B 库对应记录是否存在（用业务主键），避免盲目覆盖
- 给每条变更打唯一
trace_id，B 库入库前先查重，实现 at-least-once 投递 - 定期跑对账脚本比对 A/B 库关键字段（如
updated_at、version），发现差异走补偿流程
真正麻烦的从来不是怎么发请求，而是怎么确认对方真的收到了、真的存对了、出错了还能找回来。这部分逻辑一旦漏掉，同步系统上线三天就会开始丢数据。
