在SQL触发器中执行耗时操作会导致客户端超时，因其同步运行于事务主路径，阻塞SQL返回，而客户端超时配置（如socketTimeout）早于触发器完成即断连；wait_timeout等参数对活跃连接无效，必须将耗时逻辑剥离至应用异步、消息队列或定时任务处理。
直接说结论：在 SQL 触发器里执行耗时操作，等于把网络延迟、IO 等待、外部服务不可控性硬塞进数据库事务主路径——它不会报错，但会让 INSERT 变慢、UPDATE 卡住、连接池枯竭、锁等待飙升，最终业务大面积超时。
触发器里的耗时操作为什么会导致客户端超时
MySQL、PostgreSQL、SQL Server 的触发器全都是同步执行，且运行在发起语句的同一事务上下文中。这意味着：
-
AFTER INSERT里的 HTTP 调用没返回，整个事务就无法提交，行锁一直挂着 - 客户端等的是这条 SQL 的响应，而触发器执行时间会计入总耗时；哪怕只多花 2 秒，若应用侧
socketTimeout=1500（毫秒），就会直接断连，报错MySQL server has gone away或timeout exceeded -
wait_timeout和interactive_timeout完全不生效——它们只管“空闲连接”，而触发器执行时连接是“活跃”的 - 真正起作用的是客户端配置：
connect_timeout（建连）、net_read_timeout（收包）——但这些也不是为触发器设计的，只是被动兜底
哪些操作绝对不能放进触发器
以下行为在 OLTP 场景下属于高危操作，只要出现一次，就可能引发连锁雪崩：
- 调用
curl、http_request()、sp_OACreate等外部接口 - 写日志到远程文件系统或 NFS（如
SELECT ... INTO OUTFILE到网络路径） - 在触发器里执行
SELECT COUNT(*) FROM big_table或无索引的关联查询 - 向消息队列发消息（如
INSERT INTO kafka_outbox后立刻CALL send_kafka()）——除非这个send_kafka()是纯本地表插入，不带任何网络或阻塞逻辑 - 嵌套调用多个存储过程，尤其含游标、循环或跨库查询
注意：INSERT INTO audit_log 看似轻量，但如果 audit_log 表没建好主键或索引，或者用了 MyISAM 引擎，单次插入也可能卡住 10ms+，批量导入时放大成秒级延迟。
真正可用的替代方案（不是“怎么异步”，而是“根本不让它同步”）
核心原则：触发器只做三件事——落标记、写本地表、发通知。所有后续动作交给外部进程。
- MySQL：触发器只写
INSERT INTO outbox (table_name, pk, event_type, payload) VALUES ('orders', NEW.id, 'INSERT', JSON_OBJECT(...))；后台用SELECT ... FOR UPDATE SKIP LOCKED拉取，失败进死信表 - PostgreSQL：触发器内只执行
PERFORM pg_notify('orders_event', NEW.id::text)；worker 进程LISTEN orders_event后立即消费，自带重试与幂等 - SQL Server：必须走
SERVICE BROKER，用SEND ON CONVERSATION投递；sp_send_dbmail看似异步，实则仍在事务中，发不出就回滚 - 通用兜底：把待处理记录写入
pending_tasks表，由定时 Job（如每 30 秒）扫描并处理；适合对延迟不敏感的场景，比如日志归档、报表补数
别碰 SLEEP()、WAITFOR DELAY 或自建线程模拟异步——它们不解决根本问题，只会让锁持有时间更隐蔽、更难排查。
最容易被忽略的点：你看到的“成功”，不代表业务链路真通了
触发器执行完，INSERT 返回成功，应用日志显示“订单创建 OK”。但此时：
- MQ 消息可能因网络抖动未发出
- 缓存更新可能失败，下游读到脏数据
- 钉钉通知没发出去，运营不知道有新订单
这些失败完全被触发器掩盖了。真正的难点不在“怎么让触发器快一点”，而在于：如何设计一套能观测、可重试、带幂等、有死信的异步链路——这已经超出数据库能力边界，得靠应用层或中间件来兜底。
