窗口函数不提升聚合速度反而可能拖慢查询，因其需按PARTITION BY和ORDER BY排序并构造窗口帧，产生大量内存访问与排序开销；未指定ORDER BY或分区过大时易退化为全表扫描+全局排序。
窗口函数本身不提升聚合速度，反而可能拖慢查询；它解决的是“保留明细行 + 同时计算分组指标”这类需求，和传统 GROUP BY 是不同用途。
为什么用窗口函数后查询变慢了
窗口函数需要先按 PARTITION BY 和 ORDER BY 排序整个数据集，再逐行构造窗口帧（如 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW），这涉及大量内存随机访问和排序开销。尤其当未指定 ORDER BY 或分区过大时，ClickHouse 可能退化为全表扫描+全局排序。
- 没有
ORDER BY的COUNT(*) OVER (PARTITION BY x)仍需哈希分组，但无法利用排序索引，比等价的GROUP BY x多一次结果回填 - 带
RANGE帧且字段是DateTime时，ClickHouse 不支持INTERVAL 1 HOUR语法，必须写成秒数（如RANGE BETWEEN 3600 PRECEDING AND CURRENT ROW），否则报错Unsupported INTERVAL syntax in RANGE frame -
lead()/lag()在大数据量下容易触发Memory limit exceeded，因底层会预分配窗口缓冲区
哪些场景真能“省事又不明显变慢”
窗口函数的价值在于避免自连接或子查询，而不是加速聚合。以下写法在中小数据量（单节点、
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC)取每个用户的最新记录，替代JOIN (SELECT user_id, max(ts) FROM t GROUP BY user_id) - 用
SUM(revenue) OVER (PARTITION BY region ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)算区域累计收入，比用GROUP BY region, date后再应用程序累加更简洁 -
PERCENT_RANK() OVER (ORDER BY value)直接输出分位排名，不用手写(rank() - 1) / (count() - 1)配合两层子查询
想真正提速聚合？别依赖窗口函数
窗口函数不是性能优化工具。要加速聚合类查询，应优先考虑：
- 物化视图：用
MATERIALIZED VIEW+SummingMergeTree预算好常用分组指标，查询直接读预聚合结果 - 跳数索引：对高频过滤字段（如
status、region）建SET或MINMAX索引，减少数据扫描 - 合理分区：按时间字段（如
toDate(event_time)）分区，让查询只扫必要分区 - 避免在
OVER子句里写复杂表达式，例如COUNT(if(x > 0, 1, NULL)) OVER (...)比countIf(x > 0) OVER (...)更慢
最易被忽略的一点：窗口函数的 ORDER BY 字段必须是排序键（ORDER BY clause of the table）的前缀，否则无法利用稀疏索引加速排序——这意味着，如果表定义是 ORDER BY (region, date, user_id)，那 OVER (PARTITION BY region ORDER BY date) 能走索引，但 OVER (PARTITION BY region ORDER BY user_id) 就会强制重排序。
