触发器不能直接调用外部接口，因其设计上禁止阻塞型网络I/O；必须通过写入outbox表、LISTEN/NOTIFY或CDC工具异步解耦，由外围服务完成HTTP调用。
触发器里直接调用外部接口？不行，得绕道
SQL 标准触发器（比如 MySQL、PostgreSQL、SQL Server 的原生
）**完全不支持发起 HTTP 请求或执行系统命令**。这不是权限问题，是设计限制：触发器必须在事务上下文中快速完成，而网络 I/O 是阻塞、不可控、不可回滚的。硬要“调用外部接口”，会卡死事务、拖垮性能，甚至导致死锁或数据不一致。
可行路径只有一条：把「调用外部服务」这件事，从触发器内部移出来，交给外围程序承接。但用户真正需要的，往往是「数据一变，立刻通知下游」——所以重点不是“能不能在 trigger 里写 curl”，而是“怎么安全可靠地链路打通”。
PostgreSQL + PL/Python / PL/Perl 实现 UDF 调用 HTTP？危险，慎用
PostgreSQL 允许用
或
写函数发起 HTTP 请求，再让触发器调用它。听起来像解法，实际埋雷：
HTTP 调用失败（超时、网络断、下游挂）会导致整个
事务回滚——业务可能根本不想因通知失败丢数据
Python 的
在数据库进程里运行，容易泄漏连接、耗尽 socket、引发内存碎片
多数生产环境禁用非安全语言插件（
需重启，
默认关闭），上线前就得被 DBA 拦下
无法做重试、降级、熔断——而这些恰恰是外部调用最需要的
示例（仅说明风险，不推荐部署）：
真正落地的方案：触发器只写消息，由独立服务消费
核心思路：触发器不碰网络，只做最轻量的事——往一个地方“记一笔”。后续异步处理交给更合适的地方。
常用组合：
写入专用表
：建一张
表，字段含
、
、
、
；触发器只做
发到数据库内置队列
：PostgreSQL 可用
，MySQL 8.0+ 可用
+ 表轮询，SQL Server 用
对接外部消息中间件
：通过 CDC 工具（如 Debezium、Canal）捕获 binlog / wal，投递到 Kafka / RabbitMQ，再由消费者服务调用外部接口
优势明显：触发器毫秒级返回；失败不影响主流程；重试、限流、监控全在应用层控制；DB 不承担业务逻辑。
MySQL 触发器 + UDF 调用外部服务？基本走不通
MySQL 的
UDF 必须用 C 编写、编译成 so/dll，且只能调用纯计算类逻辑。想在 UDF 里开 socket、发 HTTP？不仅极难实现，还会让 mysqld 进程不稳定——官方明确不支持、社区也极少维护这类扩展。
常见报错包括：
、
。即使勉强跑通，升级 MySQL 版本或打补丁后大概率失效。
替代做法只有两个现实选择：
用
或
抓变更，推送到消息队列
在应用层监听关键表变更（比如 ORM 的 post_save hook），统一处理外发逻辑
别在数据库里造轮子。触发器的职责就该是校验、派生字段、维护简单衍生表——跨系统通信这事，交给 Go/Python/Java 写的服务更稳、更可测、更好查问题。
TRIGGERPL/PythonPL/PerlINSERT/UPDATErequestsshared_preload_librariesplpythonuCREATE OR REPLACE FUNCTION notify_webhook() RETURNS TRIGGER AS $$
import requests
requests.post("https://api.example.com/event", json={"table": TG_TABLE_NAME, "id": NEW.id})
return NEW
$$ LANGUAGE plpythonu;outboxevent_typepayload JSONBcreated_atstatusINSERT INTO outbox (...) VALUES (...)LISTEN/NOTIFYEVENTService BrokerCREATE FUNCTIONERROR 1126 (HY000): Can't open shared library 'http_udf.so'mysqld crashes on SELECTmysql-binlog-connectorMaxwell