数据库触发器不能直接调用HTTP服务，因其事务上下文禁止外部I/O；应通过事件表+异步消费者解耦，触发器仅记录待通知标识，由独立进程消费并调用API，确保分层架构与最终一致性。
触发器里不能直接调用 HTTP 服务
MySQL、PostgreSQL 等主流数据库的原生触发器（
、
）不支持发起网络请求，也没有内置的
或
函数。试图在触发器中写
会直接报错——这不是语法问题，是设计限制：事务上下文内不允许不可控的外部 I/O。
常见错误现象包括：
（MySQL UDF 权限不足），或 PostgreSQL 报
（未安装扩展且不推荐装）。
触发器必须轻量、可回滚、执行时间可控；HTTP 调用可能超时、失败、阻塞事务，违背这一原则
即使通过 UDF（如 MySQL 的
）或扩展（如 pgsql-http），也极难处理重试、鉴权、超时熔断等微服务集成必备逻辑
生产环境禁用此类方案：它把数据库变成了服务编排节点，破坏分层架构边界
用「写入队列 + 独立消费者」替代直连
真正可行的路径是解耦：触发器只负责可靠记录「需要通知外部服务」这件事，由另一个进程异步消费并调用微服务。核心在于选对队列载体和消费机制。
典型做法：
在业务表同库建一张轻量事件表（如
），字段至少含：
、
、
、
（INSERT/UPDATE）、
（pending/failed/success）、
触发器仅做
，语句简单、无网络依赖、可随主事务一起提交或回滚
用独立程序（Python/Go/Java 脚本）轮询该表，或监听数据库变更日志（如 MySQL binlog、PostgreSQL logical replication），提取 pending 记录后调用微服务 API
示例（PostgreSQL AFTER INSERT 触发器）：
避免轮询延迟与重复消费
轮询看似简单，但
会导致平均 500ms 延迟，而
配合短间隔又易引发锁竞争。更稳的方式是让消费端“被动唤醒”。
MySQL：用
+
或
解析 DML，输出到 Kafka/RabbitMQ，消费者从消息队列取事件
PostgreSQL：启用
，用
协议或
插件捕获变更，避免轮询
无论哪种方式，消费端必须实现幂等：微服务接口需支持
请求头，或数据库事件表加唯一约束（如
）防重入
不要在触发器里拼接 JSON 或预计算请求体
有人会在触发器里用
（MySQL 5.7+）或
（PostgreSQL）把整行数据转成 JSON 存进队列表。这看似省事，实则埋坑：
触发器内序列化性能差，尤其大字段（
、
）会拖慢主 DML
微服务接口字段常随版本迭代，硬编码 JSON 结构导致数据库层频繁改触发器，违背“数据库只管存，不参与业务逻辑”的原则
敏感字段（如
）可能意外泄露到队列表或日志中
正确做法：触发器只存最小必要标识（如
、
），由消费者按需查最新数据、过滤字段、组装请求体——这部分逻辑本就该在应用层。
微服务集成的关键不在“怎么触发”，而在“谁负责组装、谁承担失败、谁保证最终一致”。把责任推给触发器，等于让数据库背锅。
BEFORE INSERTAFTER UPDATEcurlhttp_call()SELECT http_get('https://api.example.com')ERROR 1370 (42000): execute command denied to userfunction "http_post" does not existlib_mysqludf_sysservice_call_queueidtable_namerow_idoperationstatuscreated_atINSERT INTO service_call_queue (...) VALUES (...)CREATE OR REPLACE FUNCTION queue_user_update() RETURNS TRIGGER AS $$
BEGIN
INSERT INTO service_call_queue (table_name, row_id, operation, status)
VALUES ('users', NEW.id, 'UPDATE', 'pending');
RETURN NEW;
END;
$$ LANGUAGE plpgsql;SLEEP(1)SELECT ... FOR UPDATE SKIP LOCKEDbinlogmaxwellcanallogical replicationpgoutputwal2jsonidempotency-keyUNIQUE(table_name, row_id, operation, created_at)JSON_OBJECT()row_to_json()TEXTJSONBpassword_hashuser_idorder_id