MySQL触发器无法直接发邮件或调用外部命令，可行方案是触发器仅写入trigger_failure_log表，由外部程序轮询告警；PostgreSQL可用pg_notify实时通知；SQL Server虽支持sp_send_dbmail但风险高，推荐异步日志模式。
MySQL 触发器里不能直接发邮件或调用外部命令
触发器执行失败时想自动告警，但 MySQL 的 TRIGGER 本身不支持 SLEEP 以外的系统调用，更无法直接执行 curl、mail 或写入系统日志文件。所有试图在触发器里做通知的动作，都会报错：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA 或更直接的 ERROR 1327 (42000): Undeclared variable（比如误用 @variable 未初始化）。
真正可行的做法是：把告警逻辑“推”到数据库外部，触发器只负责记录异常事实——比如插入一条失败记录到 trigger_failure_log 表，再由外部程序轮询该表。
- 建一张轻量日志表：
CREATE TABLE trigger_failure_log (id BIGINT PRIMARY KEY AUTO_INCREMENT, trigger_name VARCHAR(64), table_name VARCHAR(64), error_msg TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 在触发器中用
INSERT INTO trigger_failure_log记录上下文，**不要用SELECT ... INTO或DECLARE复杂变量**，避免语法错误 - 确保触发器内所有语句都符合
SQL SECURITY DEFINER权限模型，否则可能因权限不足静默失败
PostgreSQL 的 pg_notify 是最接近“触发即通知”的方案
PostgreSQL 允许在触发器里调用 pg_notify，它会向监听通道发送消息，外部应用可实时捕获。这比轮询高效，也比 MySQL 更贴近“触发告警”的直觉。
但要注意：消息内容只能是字符串，且长度上限为 8000 字节；接收端必须提前 LISTEN，否则消息丢失；通知不保证送达，也不重试。
- 触发器内写法示例：
PERFORM pg_notify('alert_channel', json_build_object('table', TG_TABLE_NAME, 'op', TG_OP, 'error', 'insert failed')::text); - 监听端用
psql测试：LISTEN alert_channel;，然后发通知就能看到输出 - 生产环境建议用 Python +
psycopg2的listen()模式长期守候，收到后转发到企业微信 / 钉钉 / Prometheus Alertmanager - 别在
pg_notify里传敏感字段（如手机号、身份证），消息明文可见且无加密
SQL Server 的 sp_send_dbmail 看似能直接告警，但依赖太多
SQL Server 确实允许在触发器里调用 sp_send_dbmail 发邮件，但它要求数据库邮件功能已启用、配置了合法的 SMTP 账号、且触发器运行账户有 DatabaseMailUserRole 权限。任一环节出问题，触发器就静默失败甚至阻塞业务写入。
更麻烦的是：邮件发送是异步的，但触发器执行是同步事务的一部分。如果邮件队列卡住，整个事务可能被拖慢甚至超时。
- 务必先测试：
EXEC msdb.dbo.sp_send_dbmail @profile_name='your_profile', @recipients='a@b.com', @subject='test', @body='ok'; - 触发器中调用前加
IF EXISTS (SELECT 1 FROM sys.database_mail_principal_profiles)判断是否就绪，避免硬失败 - 严禁在高并发表（如订单流水）的触发器中调用，优先走异步日志表 + 外部服务模式
- SQL Server 2019+ 可考虑用
EXTERNAL SCRIPT调 Python，但需启用sp_configure 'external scripts enabled'，安全策略更复杂
告警延迟和重复通知是真实线上最容易被忽略的点
无论用哪种方式，只要告警链路超过一层（比如触发器 → 日志表 → 定时脚本 → Webhook），就一定存在延迟。常见情况是：10 秒内连续 5 次失败，只收到 1 条聚合告警，或者收到 5 条重复消息。
解决思路不是追求“零延迟”，而是控制“可接受的抖动范围”和“去重边界”。比如按分钟级窗口聚合失败次数，或给每条日志加 UNIQUE (table_name, error_code, DATE(created_at)) 约束防爆库。
- 轮询脚本建议用
WHERE created_at > NOW() - INTERVAL 60 SECOND，而不是WHERE processed = 0，避免漏掉快速刷屏的失败 - Webhook 请求必须带幂等头，例如
X-Request-ID: ${trigger_id}-${unix_timestamp}，让接收方可丢弃重复 - 别依赖数据库时间戳做排序依据，不同节点时钟可能漂移，用
ROW_NUMBER() OVER (ORDER BY id)更稳妥
