窗口函数算同比/环比需先按时间聚合、归一化日期、补全缺失日期；ROW_NUMBER()做TOP榜须加二级排序防随机；RANK()/DENSE_RANK()不适用连续性判断，应改用LAG+条件标记+累计求和。
窗口函数怎么算同比/环比才不翻车
直接用 LAG() 或 LEAD() 算环比，但结果对不上业务报表？大概率是没处理好时间对齐和空值。业务指标（比如日活、GMV）天然有节假日波动、数据延迟补传，窗口函数不会自动跳过缺失日期或聚合重复记录。
- 必须先按时间维度
GROUP BY聚合到目标粒度（如每日汇总），再开窗——否则原始明细行数太多，LAG()会取到同一天内另一条记录，不是“昨天” - 日期字段要用
TO_DATE()或DATE()统一归一化，别直接对timestamp开窗，时区或毫秒级差异会导致LAG()错位 -
LAG(value, 1) OVER (ORDER BY dt)中的dt必须是连续、无重复的日期列；如果某天没数据，LAG()会跨天取值（比如 1号→3号，中间跳过2号），得用GENERATE_SERIES或左连接补全日期维度
用 ROW_NUMBER() 做“最近N天TOP榜”为什么总出错
想查每个用户最近7天访问最多的3个页面，写 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY cnt DESC) 却发现排名重复、TOP3漏人——问题不在函数本身，而在分区键和排序依据没对齐业务语义。
-
PARTITION BY要覆盖全部业务隔离维度，比如多租户场景下漏了tenant_id，就会跨客户混排 -
ORDER BY必须包含确定性次序：纯按cnt DESC排，若多个页面点击量相同，ROW_NUMBER()随机分配1/2/3，下次跑结果就变；得加二级排序，如ORDER BY cnt DESC, page_url ASC - 过滤条件写在窗口外（
WHERE rn ），别在 <code>OVER里试图“限制窗口大小”，SQL 不支持
监控告警里 AVG() OVER (ROWS BETWEEN ...) 性能崩了怎么办
用滑动平均检测指标突增（比如5分钟均值超阈值告警），但查询变慢甚至 OOM——根本原因是 ROWS BETWEEN 在大数据量下触发全量重排，尤其当上游没按窗口排序字段建索引时。
- 确保
ORDER BY字段（通常是时间戳）上有索引，且查询中该字段出现在WHERE条件里，否则窗口计算要扫全表 - 避免用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW计算累计值再除以行数模拟移动平均；改用固定步长：ROWS BETWEEN 4 PRECEDING AND CURRENT ROW（5行滑动）更稳 - 如果源表数据量大但监控只看最近24小时，务必先用
WHERE event_time >= NOW() - INTERVAL '24 hours'下推过滤，别让窗口函数扛全量
RANK() 和 DENSE_RANK() 在趋势断层识别里怎么选
要标记指标连续下跌天数，有人用 RANK() 减序号来判断“是否连续”，结果断层位置判错——因为 RANK() 遇到并列会跳名次，而业务关心的是物理顺序连续性，不是名次连续性。
- 识别“连续下跌”本质是找时间序列中值单调递减的最长子段，应该用行号差：
ROW_NUMBER() OVER (ORDER BY dt) - ROW_NUMBER() OVER (PARTITION BY grp ORDER BY dt)，其中grp是用条件标记下跌的布尔分组 -
RANK()适合做“同类指标横向排名”，比如各城市月度销售额排名；DENSE_RANK()适合需要紧凑名次的展示场景；两者都不适合做时间序列的连续性判断 - 真要用排名辅助趋势分析，优先考虑
LAG()+ 条件标记 + 累计求和（SUM() OVER）的组合，逻辑直白、可读性强、执行计划可控
窗口函数不是银弹，它把计算逻辑从应用层搬到SQL里，但代价是必须亲手处理时间对齐、空值传播、排序稳定性这些细节——少一个 COALESCE()，监控曲线就可能突然断崖。
