窗口函数通常比group by慢，因不减少行数且分区越大排序开销越显著；低基数partition by易引发全局排序，应优先用explain analyze对比执行计划并优化索引与order by。
窗口函数比 GROUP BY 慢是常态，但慢多少取决于分区大小
窗口函数本身不减少行数，OVER 子句定义的分区越大，内存和排序开销越明显。尤其当 PARTITION BY 字段基数低（比如全表只分 2–3 个组），数据库大概率要对整个结果集做全局排序或哈希分组，反而比先 GROUP BY 再 JOIN 更重。
实操建议：
- 用
EXPLAIN ANALYZE对比执行计划：重点看是否出现WindowAgg节点 + 大量Sort或Materialize - 若
PARTITION BY字段有索引，且分区粒度细（如按user_id分，百万用户），PostgreSQL 和 MySQL 8.0+ 可利用索引避免排序 - 避免在窗口函数中嵌套复杂表达式，比如
ROW_NUMBER() OVER (ORDER BY json_extract(data, '$.score'))—— 这会让优化器放弃索引下推
COUNT(*) OVER() vs COUNT(*) GROUP BY：别为了“顺便查总数”硬上窗口函数
想在明细结果里带一个总行数？COUNT(*) OVER() 看似简洁，但会强制数据库缓存全部中间结果。而 SELECT *, (SELECT COUNT(*) FROM t) AS total FROM t 在多数场景下更快——子查询可走索引，且不阻塞流式输出。
常见错误现象：
- 加了
COUNT(*) OVER()后查询从 200ms 崩到 3s，EXPLAIN显示Materialize节点占 90% 时间 - MySQL 5.7 不支持窗口函数，盲目抄 PostgreSQL 示例直接报错
ERROR 1064 - 在分页查询（
LIMIT/OFFSET）里用SUM(x) OVER()，导致数据库必须算完整个结果集才返回前 20 行
ORDER BY 在窗口函数里的代价常被低估
ORDER BY 不只是决定序号顺序，它触发实际排序操作。即使你只想要 LAG(col)，只要写了 ORDER BY timestamp，数据库就得按该字段排一遍——没索引就全表扫描+文件排序。
使用场景与取舍：
- 时序分析（如“上一笔订单金额”）：确保
ORDER BY字段有联合索引，例如(user_id, created_at)，配合PARTITION BY user_id - 纯排名需求（如
RANK() OVER (ORDER BY score DESC)）：如果 score 更新频繁，考虑物化排名列，而非每次查都算 - 别写
ORDER BY RAND()—— MySQL 会为每行生成随机数再排序，CPU 直接拉满
聚合函数 + 窗口函数混用时，NULL 和空分区行为不一致
SUM(sales) OVER (PARTITION BY region) 遇到某 region 全为 NULL 销售额，结果是 NULL；但 GROUP BY region 下同组 SUM() 默认返回 0（除非所有值都为 NULL）。这种语义差异在报表核对时容易漏掉。
容易踩的坑：
-
AVG()窗口函数会自动忽略NULL，但COUNT(*)不忽略——所以AVG(x) = SUM(x)/COUNT(x)在窗口里不成立 - 空分区（如某
PARTITION BY dept中 dept = 'HR' 无数据），MAX(salary) OVER (PARTITION BY dept)返回NULL，而非跳过该行 - PostgreSQL 支持
FRAME子句（如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），但 MySQL 8.0 不支持动态帧，写错直接语法报错ERROR 3587
窗口函数不是银弹，它解决的是“行级上下文感知”问题，而不是替代聚合。真正卡顿的时候，先看 OVER 里有没有不必要的 ORDER BY，再确认分区字段的选择性——这两处调不好，加再多索引也白搭。
