SQL窗口函数是一类在保留原始行的前提下，针对特定分区和排序规则进行跨行计算的函数。它和group by最大的不同在于，聚合操作不会把多行压缩成一行，而是为每一行附加一个基于相邻行算出的结果。在实时分析场景里，这种能力让我们可以在数据到达的瞬间就完成排名、累计、同比和滑动均值，而不必先存储再回头统计。
窗口函数的基本执行模型
窗口函数的核心语法是函数名配合over子句。over内部通常包含partition by、order by以及窗口帧定义。partition by决定数据如何分组，order by决定组内行的顺序，窗口帧则限定计算所覆盖的行范围。数据库或流处理引擎会先按分区和排序整理数据，再为每行打开一个逻辑上的滑动窗口。
以实时统计每个设备最近三次温度读数的平均值为例，使用rows between 2 preceding and current row就能精准框定范围。这种声明式写法比自己写状态管理代码要清晰得多，也容易让优化器选择更高效的执行计划。在流式系统中，窗口函数还会和watermark配合，处理乱序和延迟数据。
select
device_id,
read_time,
temperature,
avg(temperature) over (
partition by device_id
order by read_time
rows between 2 preceding and current row
) as avg_last_3
from device_sensor_stream;
实时分析中的典型应用模式
滑动指标与环比计算
在实时大盘中，运营最关心的是当前值对比前一周期的变化。使用lag函数可以直接取上一行的值，从而算出环比，而不需要自关联。lag和lead都属于偏移类窗口函数，它们只读取同分区内指定偏移位置的行，开销很低。
下面示例展示如何为每个用户的实时消费金额计算上一笔金额以及环比增长率。这种逻辑如果放在应用层做，需要维护每个用户的上一次状态，而在SQL里只是简单一行表达式。
select
user_id,
pay_time,
amount,
lag(amount, 1) over (
partition by user_id
order by pay_time
) as prev_amount,
(amount - lag(amount, 1) over (
partition by user_id
order by pay_time
)) / lag(amount, 1) over (
partition by user_id
order by pay_time
) as growth_rate
from user_pay_stream;
分组内排名与TopN
实时排行榜是另一类常见需求。row_number、rank和dense_rank可以在分区内为每行生成序号。结合子查询或视图，我们就能持续输出每个品类销量最高的前十个商品。在Flink SQL中，这种写法可以被优化成只维护每个分区的有限状态。
需要注意rank在遇到相同值时会产生跳号，而dense_rank不会跳号。如果业务要求严格不重不漏的TopN，通常选row_number并配合明确的时间戳兜底排序，避免并发更新时顺序不确定。
select *
from (
select
category_id,
item_id,
sale_count,
row_number() over (
partition by category_id
order by sale_count desc, update_time desc
) as rn
from category_sale_stream
) t
where rn <= 10;
在流式计算引擎中的落地要点
状态管理与资源开销
流处理里的窗口函数本质上要维护分区键的状态。如果partition by的维度基数非常高，例如按用户ID分区且用户量上亿，状态会膨胀。此时可以引入迷你批处理或者把超高频维度做近似聚合，再用窗口函数补准。
另外，窗口帧如果定义为range between interval，引擎需要缓存时间跨度内的所有行，容易引发状态过期问题。多数实时场景更推荐rows between，因为它只数行数，状态大小更可控。合理设置state ttl也能避免旧分区一直占内存。
-- 使用行数窗口帧控制状态规模
select
shop_id,
order_time,
amount,
sum(amount) over (
partition by shop_id
order by order_time
rows between 99 preceding and current row
) as sum_last_100
from order_stream;
与物化视图结合
在支持增量物化视图的数据库里，窗口函数可以被封装进视图，前端查询直接读结果。引擎会跟踪底层流水的变化，只重算受影响的分区和行。这样既享受了实时性，又避免了每次请求都全量扫流。
实践中建议把窗口函数视图和普通的明细表分开，明细表用于排查，视图用于服务看板。当发现某个指标异常时，分析人员可以下钻到同一分区的原始行，用相同的partition by和order by手动跑一次，验证窗口逻辑是否符合预期。
| 方案 | 时延 | 开发成本 | 适用场景 |
|---|---|---|---|
| 应用层自维护状态 | 低 | 高 | 逻辑极复杂且需定制 |
| SQL窗口函数+流引擎 | 秒级 | 低 | 排名、滑动、偏移类分析 |
| 离线批处理 | 小时级 | 中 | 历史复盘 |
常见误区与规避方式
一个典型误区是认为窗口函数会自动减少数据量。实际上它每行都输出，只是附加了计算列。如果在实时链路上对超大流直接select所有列加多个窗口函数，网络和CPU压力会翻倍。应当只挑选必要字段，并把多个窗口函数合并到同一个over子句里复用分区排序。
另一个误区是在order by里使用非确定性字段，导致同一批数据每次排名不同。实时系统里要尽量用事件时间或明确递增的序列号作为排序依据，避免用处理时间这类随调度变化的值。这样重放数据时结果才能稳定。
窗口函数不是替代聚合，而是补足聚合丢失的行级上下文。在实时分析中，它让流数据拥有和离线数仓同等的表达力。