不能在SQL触发器里发网络请求——这是事务模型与网络I/O本质冲突导致的硬性限制，触发器同步阻塞主事务，HTTP等操作会引发超时、锁等待、连接池耗尽及不可回滚失败，唯一安全做法是仅写入轻量队列表供外部异步处理。
不能在SQL触发器里发网络请求——这不是权限或配置问题，是数据库事务模型和网络I/O本质冲突导致的硬性限制。
触发器执行时会阻塞主事务
所有触发器逻辑都运行在原始DML事务上下文中，HTTP请求、curl调用、sp_OACreate、UTL_HTTP等操作必须同步等待响应完成。哪怕远程服务只延迟200ms，整个INSERT/UPDATE就会卡住，其他并发请求因锁等待堆积，最终触发Lock wait timeout exceeded错误。你查SHOW ENGINE INNODB STATUS会看到大量lock_mode X waiting，但日志里找不到HTTP超时记录。
- MySQL不提供原生HTTP客户端，强行用UDF或外部脚本不仅无法回滚，还可能被二进制日志机制拒绝（报错
ERROR 1419 (HY000)） - SQL Server的
sp_OACreate在2017+默认禁用，启用后仍会拖垮连接池 - Oracle的
UTL_HTTP若没设timeout参数，可能无限挂起
所谓“成功发送”其实不可靠
即使某次调用看似成功，也掩盖了三类隐性风险：
- DNS解析失败、SSL证书过期、TCP重传抖动——这些在网络层发生，触发器内无法捕获或重试
- 下游服务返回5xx或超时，但触发器已提交事务，无法补偿（HTTP失败 ≠ 事务回滚）
- 连接池耗尽：每个HTTP请求占一个数据库连接，高并发下迅速打满
max_connections
PostgreSQL用http_get()扩展？它确实能发请求，但一样会同步阻塞事务——不是“能用”，而是“用了就出事”。
容易被忽略的隐式网络I/O
很多人以为“没写curl就安全”，但以下操作同样危险：
-
SELECT * FROM OPENROWSET(...)（SQL Server）或DBLINK（PostgreSQL）——本质是跨实例同步查询，网络延迟+远端锁竞争更难排查 -
LOAD_FILE('/tmp/data.txt')（MySQL）——受OS文件锁和磁盘IO影响，等同于同步I/O - 触发器里调用自定义C函数或
plpythonu发HTTP——提权风险高，且错误堆栈常被截断
这些操作不会报“网络超时”，但在sys.dm_io_virtual_file_stats或INFORMATION_SCHEMA.PROCESSLIST里暴露异常高的io_stall或Time值，且索引优化完全无效。
唯一安全做法：只写队列表
触发器唯一该做的事，就是往一张极简表里插入一行记录：
- 表结构控制在5列以内，比如
webhook_queue(id, table_name, row_id, payload_json, created_at) - 用
AFTER INSERT/UPDATE，避免BEFORE时NEW.id为空 - payload用
JSONB（PostgreSQL）或TEXT（MySQL），只存关键变更字段，别拼全量数据 - 绝对不要在触发器里
JOIN大表、查user_details、或执行SUM()聚合
后续由独立worker（Python/Go脚本、pg_cron、SQL Agent + PowerShell）轮询这张表，失败重试、告警、更新状态。真正的复杂性和不确定性，必须交给应用层或消息队列承载。
