不能。SQL触发器因运行在事务上下文中，禁止阻塞式网络调用，主流数据库均不支持直接发邮件、Webhook或调用外部API；唯一安全做法是触发器仅写入轻量通知队列表，由外部程序异步消费并重试。
触发器里不能直接调用外部通知服务
SQL 触发器本身不支持发起 HTTP 请求、发邮件或调用消息队列，这是最常被误解的一点。你写 AFTER UPDATE ON orders 没问题，但想在触发器里直接调用 curl 或 SEND_EMAIL() 会失败——绝大多数数据库（MySQL、PostgreSQL、SQL Server）都不允许触发器执行阻塞型 I/O 操作。
常见错误现象：ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger（MySQL），或 PostgreSQL 报 cannot execute INSERT in a read-only transaction，本质都是事务上下文限制。
- 触发器只适合做轻量、事务内完成的操作：比如更新
updated_at、校验字段逻辑、写入本地日志表 - 通知逻辑必须剥离到应用层或异步任务系统中
- 关键妥协方案：触发器只负责「标记待通知」，由外部轮询或监听机制消费
用触发器写入通知队列表（推荐落地方式）
真正可落地的做法是让触发器往一张轻量的 notification_queue 表插入记录，把订单 ID、事件类型、状态变化详情等结构化存下来。后续由一个独立服务（如 Python 脚本、K8s Job 或 Kafka Consumer）定时拉取并发送通知。
示例（PostgreSQL）：
CREATE TABLE notification_queue ( id SERIAL PRIMARY KEY, order_id INTEGER NOT NULL, event_type VARCHAR(20) NOT NULL, -- 'status_changed' old_status VARCHAR(20), new_status VARCHAR(20), created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); <p>CREATE OR REPLACE FUNCTION notify_on_order_status_change() RETURNS TRIGGER AS $$ BEGIN IF NEW.status != OLD.status THEN INSERT INTO notification_queue (order_id, event_type, old_status, new_status) VALUES (NEW.id, 'status_changed', OLD.status, NEW.status); END IF; RETURN NEW; END; $$ LANGUAGE plpgsql;</p><p>CREATE TRIGGER orders_status_notify AFTER UPDATE OF status ON orders FOR EACH ROW EXECUTE FUNCTION notify_on_order_status_change();
- 务必只在
status字段实际变更时才插入，避免冗余记录 - 不要在触发器里做 JSON 序列化或复杂字符串拼接，性能差且难调试
- 表结构尽量扁平，避免外键或索引过多影响主表 UPDATE 性能
MySQL 用户注意 DELIMITER 和事务隔离问题
MySQL 的触发器语法和 PostgreSQL 差异明显，尤其在分隔符和语句嵌套上容易出错。更关键的是：MySQL 的 AFTER UPDATE 触发器运行在当前事务中，如果通知队列表写入失败（比如唯一键冲突、磁盘满），整个订单 UPDATE 会回滚——这通常不是你想要的。
- 必须用
INSERT IGNORE或ON DUPLICATE KEY UPDATE容忍写入失败 - 定义触发器前一定要加
DELIMITER $$，否则;会被提前解析 - 避免在触发器中调用存储过程处理通知，增加不可控延迟
- MySQL 8.0+ 支持
INSERT ... SELECT写队列表，但别查大表，防止锁表
为什么不用 LISTEN/NOTIFY 或 SQL Server Service Broker？
PostgreSQL 的 NOTIFY、SQL Server 的 Service Broker 确实能从数据库发出事件，但它们只是“信号”，不是“数据”。收到 NOTIFY 后你仍需在应用里再查一次订单详情，无法避免竞态（比如通知发出后订单又被改了）。
相比之下，写入 notification_queue 表是原子的、带完整上下文的、可重放的。它天然支持失败重试、去重、延迟投递等生产级需求。
真正容易被忽略的点：队列表的消费端必须实现幂等性。同一 order_id + event_type 可能被重复投递，不能假设“数据库只发一次”。
