窗口函数比子查询更适合滚动指标计算，因其避免全表扫描、支持滑动聚合、性能线性增长；需注意时间对齐、P95用PERCENTILE_CONT、异常检测建模趋势、物化视图固化结果、结果需落库再触发告警。
窗口函数比子查询更适合滚动指标计算
实时监控里“最近10条平均响应时间”“过去1小时P95延迟”这类需求，用子查询写会触发全表扫描，I/O和CPU双爆。窗口函数天然支持按时间窗口滑动聚合，数据库只需一次扫描就能产出全部结果。
- 别写
SELECT AVG(latency) FROM logs l2 WHERE l2.ts BETWEEN l1.ts - INTERVAL '10 minutes' AND l1.ts—— 这是O(n²)复杂度，数据量一上万就卡住 - 改用
AVG(latency) OVER (ORDER BY ts ROWS BETWEEN 9 PRECEDING AND CURRENT ROW)，性能线性增长 - 时间对齐必须显式处理：用
FLOOR(UNIX_TIMESTAMP(ts) / 600) * 600而不是DATE(ts), HOUR(ts), MINUTE(ts) DIV 10，否则窗口边界错位 - P95延迟别用
AVG()，改用PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency)，避免毛刺污染水位判断
用窗口函数识别异常模式而非单点阈值
单纯查“延迟 > 1000ms”只能抓毛刺，漏掉缓慢劣化。窗口函数能建模趋势，比如连续3次超阈值、同比上涨50%、偏离移动均值3σ——这才是有效告警信号。
-
COUNT(*) OVER (ORDER BY ts RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW)配合HAVING判断短时突增 -
LAG(latency, 1) OVER (PARTITION BY service_name ORDER BY ts)算同比变化，注意LAG()返回 NULL 时要COALESCE(..., 0)避免整个表达式变 NULL - 分组用
PARTITION BY service_name, endpoint，别漏掉关键维度，否则跨服务干扰判断 - ORDER BY 必须带唯一排序键（如
ts, log_id），否则相同时间戳下窗口行为不可预测
物化视图 + 窗口函数 = 可靠告警快照
直接在大表上跑窗口函数仍可能慢，尤其当监控表没索引或数据量超千万。把窗口计算结果固化到物化视图，再由外部轮询服务读取，才是生产级做法。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- PostgreSQL 示例：
CREATE MATERIALIZED VIEW hourly_p95_latency AS SELECT service_name, FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/3600)*3600) AS hour_start, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency) AS p95 FROM logs WHERE ts >= NOW() - INTERVAL '24 hours' GROUP BY service_name, hour_start; - 刷新策略用
REFRESH CONCURRENTLY，避免锁表；定时任务每5分钟执行一次REFRESH MATERIALIZED VIEW CONCURRENTLY hourly_p95_latency - 轮询脚本查最新记录时，加
WHERE hour_start = (SELECT MAX(hour_start) FROM hourly_p95_latency)，别用ORDER BY hour_start DESC LIMIT 1—— 后者无法走索引 - MySQL 没物化视图，得用事件+临时表模拟，但要注意
INSERT ... SELECT在大表上可能阻塞写入
窗口函数结果不能直接发告警
窗口函数只是计算，不带触发能力。必须把结果落库或发通知，再由独立服务消费——这是最容易被忽略的架构断点。
- 别在查询里嵌
NOTIFY或调存储过程发邮件，PG 的 NOTIFY 是异步的，且无法保证投递顺序 - 推荐路径：窗口函数 → 物化视图/监控表 → 外部服务轮询 → 触发告警（邮件/SMS/钉钉）
- 监控表字段至少含
metric_name、value、check_time、status（如'WARN'/'OK'），状态字段必须显式更新，别依赖隐式默认值 - 每次写入前先
DELETE FROM monitor_summary WHERE metric_name = 'p95_latency'，否则旧值残留导致误告
窗口函数本身很稳，但落地链路里每一步都可能出错：时间对齐偏差、NULL 处理遗漏、物化视图刷新延迟、状态字段未覆盖写入——这些细节不压测根本发现不了。
