不能在触发器里直接调用外部API，MySQL会因权限不足、插件禁用或静默失败而报错，PostgreSQL虽支持但同步阻塞风险高；可靠方案是触发器仅写队列表，由外部服务异步处理。
不能在触发器里直接调用外部 API，强行这么做大概率导致事务卡死、数据库不稳定或安全策略拦截。
MySQL 触发器里调用 curl 或 UDF 会报什么错
MySQL 原生不支持网络请求，任何试图在触发器中执行 HTTP 调用的操作都会失败：
-
ERROR 1370 (42000): execute command denied to user ''@'localhost' for routine 'sys.eval'（启用mysqlx或自定义函数但权限不足） -
ERROR 1123 (HY000): Can't initialize function 'http_post'; Plugin is disabled（UDF 加载失败，常见于secure_file_priv限制或 SELinux 拒绝） - 静默失败：UDF 内部
curl_easy_perform()超时后返回 NULL，触发器继续执行但没做任何事，错误日志里也找不到痕迹
根本原因不是语法写错，而是 MySQL 运行环境刻意隔离了网络和系统调用能力——这是设计使然，不是配置能绕过的。
PostgreSQL 的 http_post 看似可行，但实际很危险
pgsql-http 扩展确实提供了 http_post() 函数，可以在触发器中直接调用，但它默认同步阻塞事务：
- 目标服务响应慢（比如 CDN 刷新接口耗时 2s），整个
INSERT就卡住 2s，高并发下连接池迅速打满 - 遇到
Connection refused或SSL certificate verify failed，触发器抛异常 → 当前事务回滚 → 业务写入失败 - 无法区分是网络抖动还是永久性故障，重试逻辑必须手写在 PL/pgSQL 里，且容易漏掉
RAISE WARNING以外的错误传播路径
哪怕加了 BEGIN ... EXCEPTION 捕获，也只是“不崩”，不代表“可靠”——失败事件完全丢失，没有持久化、无重试、无监控入口。
真正能上线的方案：触发器只写队列表，其他交给外部服务
核心原则是把数据库当“记账本”，而不是“执行器”。所有网络、鉴权、重试、限流、日志都剥离出去。
- 建一张轻量队列表，例如
cdn_refresh_queue，字段至少含：id、table_name、row_id、cache_key_pattern（如"article:{id}"）、status（'pending'/'success'/'failed'）、created_at - 在业务表上建
AFTER INSERT/UPDATE/DELETE触发器，仅执行一条INSERT INTO cdn_refresh_queue (...) VALUES (...)；DELETE用OLD.id，别拼 URL - 外部服务（Python/Go/云函数）每 3–5 秒轮询一次
status = 'pending'的记录，每次最多取 10 条，用cache_key_pattern替换出真实 key，再构造 CDN API 所需的{"urls": [...]}请求体 - 调用 CDN 接口时必须设
timeout=3，对429、401、503等错误码单独处理，失败后更新status = 'failed'并记录error_code字段，供后续人工或自动重试
这个模式下，触发器执行时间稳定在 0.5ms 以内，数据库完全不受外部服务波动影响。最容易被忽略的是：队列表没加 INDEX ON status, created_at，轮询变全表扫描，几万条记录后延迟飙升。
