SQL Server中触发器内直接调用sp_send_dbmail会同步阻塞事务，导致锁表、超时甚至死锁；MySQL/PostgreSQL触发器无法安全发邮件，必须通过轻量写入队列表+外部异步消费解耦。
触发器里调 sp_send_dbmail 会同步阻塞事务
SQL Server 的 sp_send_dbmail 是同步执行的：它发完邮件、收到 SMTP 响应后才返回。一旦邮件服务器响应慢（比如网络延迟 1.5 秒、DNS 解析卡顿、SMTP 队列积压），整个 INSERT/UPDATE 事务就会原地等待，锁住目标表行或页，其他并发操作跟着排队——这不是“慢”，是真挂起。
常见现象包括：
- 客户端报
Timeout expired，但 SQL Server 日志里查不到明确错误 -
sys.dm_exec_requests显示该会话wait_type = ASYNC_NETWORK_IO或LCK_M_U - 死锁图里出现
trg_after_insert_order → sp_send_dbmail调用链
MySQL / PostgreSQL 触发器根本不能发邮件
MySQL 内核在触发器上下文中直接禁止任何系统调用：SYS_EXEC()、SELECT ... INTO OUTFILE、甚至 curl 命令都会触发 ERROR 1419 或 ERROR 1370。这不是权限没开够，是设计上就拒绝 I/O。
PostgreSQL 更严格：PERFORM pg_notify() 在触发器函数里直接报错 cannot issue NOTIFY in a trigger function；dblink 虽能连外部服务，但触发器内调用仍受事务约束，失败时无法回滚 HTTP 请求。
强行绕过只会让问题更隐蔽：
- MySQL 启用
lib_mysqludf_sys→sys_exec异步发信 → 事务回滚了，邮件却已发出 - PostgreSQL 用
pg_cron定时查表 → 轮询间隔导致通知延迟，且无可靠幂等机制
事务回滚后邮件无法撤回是硬伤
数据库事务的原子性只管数据，不管外部副作用。你在触发器里调 sp_send_dbmail，哪怕后续因为主键冲突、外键不匹配或显式 ROLLBACK 导致事务失败，邮件早已通过 SMTP 协议发出去了。
这带来两个实际风险：
- 用户收到“订单创建成功”邮件，但数据库里根本没插入成功
- 下游系统基于邮件触发动作（如发货），结果发现订单状态为空
没有 XA 分布式事务支持，这种跨边界操作天然不可靠。
真正能落地的解耦结构长什么样
所有稳定系统都把通知逻辑移出触发器边界。核心就三点：轻量写入、异步消费、状态持久化。
例如 PostgreSQL 的最小可行结构：
CREATE TABLE notify_queue ( id BIGSERIAL PRIMARY KEY, event_type TEXT NOT NULL, payload JSONB NOT NULL, status TEXT DEFAULT 'pending', created_at TIMESTAMPTZ DEFAULT NOW(), updated_at TIMESTAMPTZ ); CREATE INDEX idx_notify_pending ON notify_queue (status, created_at) WHERE status = 'pending';
触发器只做一件事：
BEGIN
INSERT INTO notify_queue (event_type, payload)
VALUES ('user_registered', jsonb_build_object('user_id', NEW.id));
RETURN NEW;
END;
外部进程（Python 脚本或 pg_cron 作业）轮询时加 FOR UPDATE SKIP LOCKED，处理完再 UPDATE ... SET status = 'sent'。漏掉的记录下次还能重试。
复杂点不在“能不能发”，而在队列表索引是否覆盖查询条件、轮询频率怎么设才不压垮 DB、失败重试要不要加退避、以及如何避免重复消费——这些细节决定你上线后会不会半夜被报警叫醒。
