应禁用触发器内网络I/O，改用异步队列：MySQL写消息表+轮询，PostgreSQL用LISTEN/NOTIFY；所有HTTP、文件读写、跨库查询均须剥离出事务，保障主DML不被阻塞。
因为触发器执行时会阻塞主事务，网络I/O请求极大概率导致超时、连接池耗尽或事务长时间挂起，直接拖垮整个DML操作的可用性。
触发器里发HTTP请求会卡住整个INSERT/UPDATE事务
SQL触发器运行在数据库事务上下文中，所有操作（包括你写的curl、UTL_HTTP、sp_OACreate等）都同步等待完成。一旦远程服务响应慢（哪怕只是200ms），当前事务就卡住，其他并发请求可能因锁等待堆积——SHOW ENGINE INNODB STATUS里会出现lock_mode X waiting提示，而错误日志里却只报“Lock wait timeout exceeded”这种误导性信息。
- MySQL不原生支持HTTP客户端，硬要调用需依赖UDF或外部脚本，稳定性差且无法被事务回滚
- SQL Server用
sp_OACreate发起HTTP请求时，若目标不可达，会默认等待60秒才失败 - Oracle的
UTL_HTTP在触发器中调用，若未设timeout参数，可能无限期挂起
替代方案不是“换一个更稳的HTTP库”，而是彻底移出触发器
网络调用天然不可靠、不可预测、不可回滚，和触发器“强一致性+强事务绑定”的设计哲学根本冲突。正确做法是把这类逻辑下沉到应用层或异步管道：
- 触发器只做轻量记录：例如写入一张
outbound_queue表，字段含target_url、payload、status - 由独立服务（如Go/Python worker）轮询该表，成功后更新
status = 'done'，失败则重试或告警 - 如果必须实时通知，改用数据库内建的轻量机制：MySQL的
SIGNAL抛出自定义异常供应用捕获；PostgreSQL的NOTIFY发消息给监听端
容易被忽略的隐式IO：文件系统访问和DBLINK跨库查询
很多人以为“没写HTTP就是安全的”，但以下操作同样属于危险I/O：
-
SELECT ... FROM OPENROWSET（SQL Server）或CREATE FUNCTION ... EXTERNAL NAME（Oracle）——本质仍是同步远程调用 - 触发器里读写本地文件（如
SELECT LOAD_FILE('/tmp/data.txt')），受OS文件锁和磁盘延迟影响 - 通过DBLINK或FEDERATED引擎查另一台数据库的表——网络延迟+远端锁竞争，比HTTP更难排查
这些操作不会报“网络超时”，但会在sys.dm_io_virtual_file_stats或INFORMATION_SCHEMA.PROCESSLIST里暴露异常高的io_stall或Time值，且无法通过索引优化缓解。
