如何通过SQL聚合结果自动化触发业务告警？

必须将聚合结果写入可被外部程序消费的载体（如专用监控表或通过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分钟内重复触发，只发第一次，后续合并进摘要消息——这层逻辑数据库做不了，得放在下游消费服务里。