在业务系统运行过程中，数据库里的关键表偶尔会被错误程序或越权操作写入异常数据，例如订单金额为负数、状态字段出现非法枚举值。如果仅仅依赖定时脚本去扫表，发现问题时往往已经过去了数小时。利用数据库自身的触发器机制，可以在INSERT、UPDATE、DELETE语句执行的同一事务上下文里立刻识别异常，并触发通知动作，从而把风险暴露时间压缩到秒级。
触发器捕捉异常事件的基本原理与写法
触发器是附着在表或视图上的一种特殊存储过程，当定义的事件（如AFTER INSERT）发生时由数据库引擎自动调用。要捕捉异常事件，通常的思路是在触发器内部访问插入或更新前后的数据映像表（MySQL中是NEW与OLD，SQL Server中是inserted与deleted），然后编写条件判断逻辑来识别不符合业务规则的记录。比如规定用户余额不能低于零，那么在AFTER UPDATE触发器里检查NEW.balance是否小于零即可。
下面以MySQL为例展示一个基础的异常检测触发器。它在用户账户表发生更新后，若余额变成负数就向一张预警记录表写入事件，后续再由外部程序读取该表发送通知。这种方式把通知发送和事务主体解耦，避免触发器内部直接调用外部网络导致主事务被拖慢或死锁。
DELIMITER $$
CREATE TRIGGER trg_account_audit
AFTER UPDATE ON account
FOR EACH ROW
BEGIN
IF NEW.balance < 0 THEN
INSERT INTO alert_event (tbl_name, row_id, msg, created_at)
VALUES ('account', NEW.id, '余额变为负数', NOW());
END IF;
END$$
DELIMITER ;
上述写法虽然简单，但需要注意触发器是行级还是语句级。MySQL的FOR EACH ROW是行级触发，若一次更新影响上万行，触发器会被执行上万次，此时应评估性能影响。另外，在触发器里写复杂的查询或锁表操作极易引发锁等待，因此只做轻量判断和单条插入是较稳妥的实践。
通过扩展机制实现直接外发通知的三种路径
仅仅把异常写进表还不够自动，真正的预警要求信息主动抵达负责人。第一种路径是利用数据库自带的扩展存储过程或组件，例如在SQL Server中启用Database Mail后，可以在触发器里调用sp_send_dbmail直接发邮件。但这种做法把外部网络依赖放进事务，一旦邮件服务不通，更新语句也会失败或挂起，因此生产环境常配合TRY CATCH包裹，失败仅记日志不阻断业务。
第二种路径是SQL Server的CLR集成，允许用C#写托管存储过程，在触发器里调用HttpClient把异常JSON推送到企业微信或钉钉。相比T-SQL发邮件，CLR更灵活且能走内部消息网关，但部署前需将数据库设为TRUSTWORTHY并注册程序集，运维门槛较高。第三种路径是前面提到的预警表加独立消费者，触发器只插表，一个常驻服务用短间隔轮询或利用Service Broker异步接收，再发通知。该方案对数据库侵入最小，也最容易跨多种数据库统一架构。
-- SQL Server 中使用邮件扩展的简化示例
CREATE TRIGGER trg_order_guard
ON orders
AFTER INSERT
AS
BEGIN
IF EXISTS (SELECT 1 FROM inserted WHERE total_amount < 0)
BEGIN
BEGIN TRY
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'ops_profile',
@recipients = 'dba@ipipp.com',
@subject = '订单异常预警',
@body = '检测到订单金额为负数';
END TRY
BEGIN CATCH
INSERT INTO alert_event (msg) VALUES ('邮件发送失败，但数据已记录');
END CATCH
END
END;
从维护角度看，预警表加消费者的方式最清晰：数据库负责忠实记录，外部程序负责渠道适配。当邮件网关更换为短信或Webhook时，只需改消费者，不必动线上触发器。而CLR和内置邮件适合对延迟极度敏感且数据库版本可控的内网系统。
事务一致性与性能影响的权衡策略
把通知逻辑放进触发器最大的争议在于事务边界。如果触发器内部动作是主事务的一部分，那么通知失败会导致业务回滚，这显然违背了预警的初衷。因此业界普遍建议触发器只做同步写表，真正的发送走异步。在MySQL中还可利用Binlog订阅（如Canal）替代轮询，由下游消费Binlog里的变更事件并过滤异常，这样连预警表都不用建，进一步降低数据库负担。
性能方面，行级触发器在高频写入表上可能成为瓶颈。一个可行的优化是只在确实重要的列上建触发器，或通过应用程序在提交前先做一层校验，数据库触发器作为最后防线。同时应为预警表建立合理索引和定期归档，避免其无限膨胀拖慢插入。以下表格对比了不同方案在一致性与性能上的表现：
| 方案 | 事务耦合度 | 部署复杂度 | 适用场景 |
|---|---|---|---|
| 触发器内直接发邮件 | 高，可能阻塞 | 低 | 内网低并发管理库 |
| CLR托管过程推送 | 中，需异常处理 | 高 | 统一技术栈Windows环境 |
| 预警表加外部消费者 | 低，完全异步 | 中 | 绝大多数生产业务 |
| Binlog外部消费 | 无侵入 | 中高 | MySQL海量写入场景 |
综合来看，自动发送SQL预警通知并不是单纯写一个触发器就能完事，而是要在捕捉异常、保证主库性能、确保通知可达之间做工程取舍。对于刚起步的团队，先从预警表加简单轮询脚本开始，验证异常规则覆盖面；当规则稳定后再考虑引入消息队列或Binlog方案，既控制风险又留有演进空间。