不能。SQL触发器因运行在事务上下文中，禁止阻塞式网络调用，不支持直接发邮件或调用外部服务；正确做法是触发器仅写入通知队列表，由外部程序异步处理发送。
触发器里不能直接发邮件
SQL 标准触发器（CREATE TRIGGER）本身不支持调用外部服务（如 SMTP），也不允许执行 SEND MAIL、UTL_MAIL.SEND（Oracle）、sp_send_dbmail（SQL Server）等发信操作——除非数据库明确支持且已启用对应扩展，且触发器有足够权限。更关键的是，**在事务上下文中发邮件失败会导致整个事务回滚**，这违背“通知是副作用，不应影响主业务”的设计原则。
常见错误现象：ORA-04092: cannot commit in a trigger（Oracle 中调 UTL_MAIL 后隐式 commit）、Msg 39023, Level 16（SQL Server 中 sp_send_dbmail 在只读事务中被禁用）。
- 触发器应只做轻量、确定性、无副作用的操作（如日志写入、状态标记）
- 发邮件属于异步、可能失败、耗时的操作，必须剥离出事务边界
- 若强行在触发器内调用发信过程，一旦邮件服务不可用，原
INSERT/UPDATE就会失败，用户看到的是业务异常而非通知失败
正确做法：触发器只写审计日志，另起进程轮询发送
把“捕获异常修改”拆成两步：先由触发器记录可疑变更到专用表，再由外部调度器（或数据库作业）定期查该表、发邮件、标记已处理。这样解耦清晰，失败不影响主流程。
使用场景举例：监控 users 表中 salary 字段被非 HR 角色大幅修改（±30% 以上）；或 status 字段被绕过审批流程直接设为 'active'。
- 建一张审计表：
audit_alerts，含字段：id、table_name、row_id、old_value、new_value、alert_type、created_at、sent_at - 触发器中只做：
INSERT INTO audit_alerts (...) VALUES (...)，不加事务控制（自动继承外层事务，但插入失败才影响主事务，风险可控） - 避免在触发器里查其他表（如
roles表判断权限），否则易引发死锁；权限逻辑应前置到应用层或用视图+策略控制
SQL Server 示例：用 sp_send_dbmail + 代理作业
SQL Server 是少数能在数据库内较安全完成闭环的场景，但仍有硬约束：必须用 SQL Server Agent 作业调用发信，不能在触发器里直调。
CREATE TRIGGER tr_users_salary_alert ON users AFTER UPDATE AS IF UPDATE(salary) BEGIN INSERT INTO audit_alerts (table_name, row_id, old_value, new_value, alert_type) SELECT 'users', i.id, d.salary, i.salary, 'salary_jump' FROM inserted i JOIN deleted d ON i.id = d.id WHERE ABS((i.salary - d.salary) * 1.0 / NULLIF(d.salary, 0)) > 0.3; END
然后创建一个每分钟运行一次的 Agent 作业，执行：
DECLARE @body NVARCHAR(MAX);
SELECT @body = STRING_AGG(
CONCAT('ID:', row_id, ' from ', old_value, ' to ', new_value),
'; '
) FROM audit_alerts WHERE sent_at IS NULL;
<p>IF @body IS NOT NULL
BEGIN
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'DBAlerts',
@recipients = 'admin@company.com',
@subject = 'Suspicious salary changes detected',
@body = @body;</p><p>UPDATE audit_alerts SET sent_at = GETDATE() WHERE sent_at IS NULL;
END</p>
-
STRING_AGG需 SQL Server 2017+；低版本可用FOR XML PATH - 务必加
WHERE sent_at IS NULL条件，避免重复发送 - Agent 作业失败时会留日志，可配置失败告警，比触发器内静默失败更可靠
PostgreSQL 或 MySQL 怎么办？靠外部脚本轮询
PostgreSQL 没内置邮件过程；MySQL 的 mysqlpump 或 event_scheduler 也不适合发信。这时必须跳出数据库，用外部程序承担“查日志 + 发邮件”职责。
推荐最小可行方案：一个 Python 脚本，用 psycopg2 或 pymysql 连接，定时执行：
SELECT id, table_name, row_id, alert_type FROM audit_alerts WHERE sent_at IS NULL LIMIT 100;
查到后拼邮件内容，调 smtplib 发送，再 UPDATE audit_alerts SET sent_at = NOW() WHERE id IN (...)。
- 用
systemd timer（Linux）或Windows Task Scheduler控制执行频率，比数据库作业更灵活 - 脚本里加重试逻辑（如发信失败则
sent_at = 'retrying'，下次跳过），避免单次网络抖动导致积压 - 注意连接池和超时设置，防止脚本卡住或连爆数据库
真正难的不是写触发器，而是设计好日志结构、隔离好同步/异步边界、并让失败可追踪——这些细节没处理好，通知系统反而会成为故障放大器。
