窗口函数算同比/环比需先按时间聚合、归一化日期、补全缺失日期；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号）。这时，就需要借助GENERATE_SERIES或左连接来预先补全日期维度表。
用 ROW_NUMBER() 做“最近N天TOP榜”为什么总出错
想找出每个用户最近7天访问量最高的3个页面，逻辑看似简单，写出来的SQL却可能产生排名重复或漏掉关键数据的情况。问题通常出在分区和排序的逻辑没有完全贴合业务语义。
- 分区要全面：
PARTITION BY必须覆盖所有必要的业务隔离维度。例如在多租户系统中，如果漏掉了tenant_id，就会导致不同客户的数据混杂在一起排序。 - 排序需确定：
ORDER BY必须提供确定性的次序。如果仅按cnt DESC（点击量降序）排列，当多个页面的点击量完全相同时，ROW_NUMBER()会随机分配1、2、3名，导致每次查询结果都可能变化。正确的做法是增加一个二级排序字段，例如ORDER BY cnt DESC, page_url ASC。 - 过滤在窗口外：限制排名结果（例如取前三）的过滤条件，应该写在窗口函数之外（如
WHERE rn <= 3）。别试图在OVER()子句里直接“限制窗口大小”，标准的SQL语法并不支持这种操作。
监控告警里 A VG() OVER (ROWS BETWEEN ...) 性能崩了怎么办
用滑动平均来检测指标突增（比如5分钟均值超过阈值则告警），是一个常见的监控策略。但如果查询速度急剧下降甚至引发内存溢出，那很可能是窗口计算方式触发了低效的执行计划。
- 索引是关键：确保
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() 处理空值，就足以让监控曲线呈现断崖式的错觉。
