必须将聚合结果写入可被外部程序消费的载体（如专用监控表或通过NOTIFY推送），再由独立服务触发告警；MySQL用EVENT定时聚合写入，PostgreSQL用物化视图+NOTIFY实现更及时链路；需注意口径一致性、状态持续性与告警抑制三要点。
不能靠触发器直接发告警，必须把聚合结果输出到可被外部程序消费的载体里——要么写表、要么发通知信号，再由独立服务完成真实告警动作。
聚合查询结果怎么落地成告警依据
聚合本身只是计算，不带触发能力。你需要让聚合结果“可观察”，常见做法是把结果 INSERT 到一张专用监控表（如 monitor_summary），字段至少含 metric_name、value、check_time、status（比如 'WARN'/'OK'）。
- 别用视图或临时表——它们无法被轮询脚本稳定读取
- 每次写入前先
DELETE FROM monitor_summary WHERE metric_name = 'order_fail_rate'，避免旧值干扰判断 - 如果聚合耗时高（如扫描千万级订单表），加
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 HOUR)限定范围，别全表扫 - MySQL 下记得给
metric_name和check_time加联合索引，否则轮询查最新记录会变慢
MySQL 里怎么让聚合结果自动写入告警表
用事件调度器（EVENT）定时执行聚合+写入，比应用层调用更可控，也避开触发器不能跨表聚合的限制。
- 开启调度器：
SET GLOBAL event_scheduler = ON - 建事件示例（每5分钟检查一次失败率）：
CREATE EVENT check_order_fail_rate ON SCHEDULE EVERY 5 MINUTE DO INSERT INTO monitor_summary (metric_name, value, check_time, status) SELECT 'order_fail_rate', IFNULL(failed_cnt / NULLIF(total_cnt, 0), 0), NOW(), CASE WHEN IFNULL(failed_cnt / NULLIF(total_cnt, 0), 0) > 0.05 THEN 'WARN' ELSE 'OK' END FROM ( SELECT COUNT(*) FILTER(WHERE status = 'failed') AS failed_cnt, COUNT(*) AS total_cnt FROM orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 1 HOUR) ) t; - 注意：MySQL 5.7 不支持
FILTER，得用SUM(IF(status='failed',1,0))替代 - 事件默认在
definer权限下运行，确保该用户有对monitor_summary的 INSERT 权限
PostgreSQL 怎么用物化视图+NOTIFY 实现实时告警链路
物化视图保证聚合结果快照可查，NOTIFY 把变更推给监听进程，比轮询更及时且无空查开销。
- 先建物化视图：
CREATE MATERIALIZED VIEW order_fail_summary AS SELECT COUNT(*) FILTER (WHERE status = 'failed')::float / NULLIF(COUNT(*), 0) AS fail_rate, NOW() AS updated_at FROM orders WHERE created_at >= NOW() - INTERVAL '1 hour';
- 再建刷新函数和触发器：
CREATE OR REPLACE FUNCTION refresh_and_notify() RETURNS TRIGGER AS $$ BEGIN REFRESH MATERIALIZED VIEW order_fail_summary; PERFORM pg_notify('alarm_channel', json_build_object('metric', 'order_fail_rate', 'value', (SELECT fail_rate FROM order_fail_summary))::text ); RETURN NULL; END; $$ LANGUAGE plpgsql; - 最后绑定到定时任务（如
pg_cron）或用pgAgent每分钟调用一次refresh_and_notify() - 监听端用 Python 的
psycopg2长连接LISTEN alarm_channel，收到 payload 后解析并调用钉钉 Webhook
告警逻辑里最容易被忽略的三个点
一是聚合口径漂移：今天按小时算失败率，明天改成按天，但告警阈值没同步调整，导致误报或漏报；二是状态持续性：单次超限就发告警，但实际可能是瞬时抖动，应加“连续2次超限”或“过去5分钟均值 > 阈值”条件；三是告警抑制：同一业务异常在10分钟内重复触发，只发第一次，后续合并进摘要消息——这层逻辑数据库做不了，得放在下游消费服务里。
