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