SQL触发器无法直接发送Webhook，唯一安全做法是向轻量队列表（如webhook_queue）插入变更记录；外部进程轮询该表并执行HTTP推送。
SQL触发器不能直接发送Webhook通知——所有尝试在触发器里调用curl、requests、sp_send_dbmail或EXEC xp_cmdshell的做法，都会失败或引发严重问题。
MySQL 触发器里写 SELECT INTO OUTFILE 或调用 SYS_EVAL 会报错
MySQL 8.0+ 默认禁用危险函数，且触发器上下文完全不支持网络 I/O。常见错误：ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled，本质是权限 + 二进制日志双重限制。即使绕过权限，也无法发起 HTTP 请求。
- 触发器唯一安全动作：向一张轻量监控表（如
webhook_queue）插入一行 - 字段建议包含：
table_name、event_type、row_id、changed_field、old_value、new_value、trigger_time、user_host - 避免在触发器中用
JSON_OBJECT()拼全量字段——只取关键变化字段，比如只记录status从'pending'变为'failed' - 别查大表、别 JOIN、别用子查询——否则主业务 INSERT/UPDATE 会明显变慢
PostgreSQL 的 NOTIFY 不能在触发器函数里直接调用
看似能用的 NOTIFY 实际会报错：ERROR: cannot issue NOTIFY in a trigger function。这不是配置问题，是 PostgreSQL 内核强制限制：事务内不允许发出异步信令。
- 正确做法：用
AFTER INSERT或AFTER UPDATE触发器，把变更事件写入专用队列表（如webhook_queue） - 必须用
AFTER——BEFORE时NEW.id可能为空（尤其用SERIAL或IDENTITY） - payload 字段推荐用
JSONB类型，存精简结构：jsonb_build_object('table', 'config_settings', 'key', 'feature_x', 'old', OLD.value, 'new', NEW.value) - 不要在触发器里调用自定义 C 函数或扩展（如
pgmq）来“绕过”限制——增加维护成本且不保证事务一致性
SQL Server DML 触发器调用 sp_send_dbmail 会卡死事务
哪怕你有 DBMail 权限，AFTER UPDATE 里调用 sp_send_dbmail 也会让整个事务阻塞等待邮件发送完成，极端情况下导致连接超时或死锁。
- 只允许在触发器中执行最轻量操作：INSERT INTO
webhook_queue（该表应只有几列、无索引膨胀） - 避免用
INSERT ... SELECT从大表拉数据——哪怕加了TOP 1，也容易引发锁升级 - 如果需要区分“特定字段修改”，用
CASE WHEN OLD.status NEW.status THEN 'status_changed' END判断，而不是IF UPDATE(status)（它只判断是否被 SET，不判断值是否真变了） - 别在触发器里用
TRY...CATCH包裹 Webhook 发送逻辑——那根本没用，因为 Webhook 发送本身就不该在这儿做
真正可行的链路：触发器埋点 + 外部进程消费
所谓“自动发送 Webhook”，实际是三段式协作：触发器写队列 → 定时/长连接进程读队列 → 脚本调用 curl 或 requests.post() 推送。这个外部进程才是唯一能碰网络的地方。
- 轮询脚本示例（MySQL）：
mysql -Nse "SELECT id, payload FROM webhook_queue WHERE delivered = 0 ORDER BY id LIMIT 10" | while read id payload; do curl -X POST -H "Content-Type: application/json" -d "$payload" https://your-webhook-url && mysql -e "UPDATE webhook_queue SET delivered = 1 WHERE id = $id"; done - PostgreSQL 更推荐 LISTEN/NOTIFY 配合外部监听进程（但注意：NOTIFY 仍不能在触发器函数里发，得靠一个独立的
pg_cronjob 或应用层定时任务去查webhook_queue并PERFORM pg_notify()） - 关键细节：消费完必须立刻
UPDATE webhook_queue SET delivered = 1 WHERE id = ?，否则重复推送；建议加FOR UPDATE SKIP LOCKED防并发冲突 - 敏感字段（如密码、手机号）绝不能进
payload字段——只传业务标识（如order_id），下游服务按需查库
最容易被忽略的一点：队列表的 delivered 字段必须设为 BOOLEAN DEFAULT FALSE，且所有消费逻辑都基于它做原子更新。一旦漏掉这步标记，或者用 DELETE FROM 清理队列（而非 UPDATE），就会丢通知或重复发——而这种问题在线上往往延迟数小时才暴露。
