窗口函数性能调优：避开那些让你查询变慢的“隐形坑”
先说一个核心判断：窗口函数比 GROUP BY 慢，这几乎是常态。但具体慢多少，很大程度上取决于你定义的分区大小。
窗口函数比 GROUP BY 慢是常态，但慢多少取决于分区大小
窗口函数有个特点：它不减少最终结果的行数。这意味着，OVER子句里定义的分区越大，背后的内存和排序开销就越明显。尤其当PARTITION BY字段的基数很低时——比如全表数据只分成两三个大组——数据库大概率得对整个结果集进行一次全局排序或哈希分组。这种情况下，它的开销反而可能比先做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()后，查询时间从200毫秒直接崩到3秒，EXPLAIN一看，90%的时间都花在了Materialize节点上。 - 在MySQL 5.7的环境里，盲目照搬PostgreSQL的窗口函数示例，结果直接报出
ERROR 1064语法错误。 - 在分页查询（
LIMIT/OFFSET）里使用SUM(x) OVER()，导致数据库必须计算完整个结果集，才能返回前20行，完全丧失了分页的意义。
ORDER BY 在窗口函数里的代价常被低估
这里需要特别警惕：窗口函数里的ORDER BY，可不仅仅是决定一个序号顺序那么简单，它会触发实实在在的排序操作。即便你只是想用LAG(col)取前一行的值，只要写了ORDER BY timestamp，数据库就得按这个字段把数据排一遍——如果没有合适的索引，全表扫描加文件排序就跑不掉了。
不同场景下的取舍策略：
- 时序分析（比如计算“上一笔订单金额”）：务必确保
ORDER BY的字段有联合索引支持。例如，配合PARTITION BY user_id，建立(user_id, created_at)这样的索引，效率会高很多。 - 纯排名需求（例如
RANK() OVER (ORDER BY score DESC)）：如果score字段更新非常频繁，与其每次查询都实时计算排名，不如考虑定期物化排名结果到另一列。 - 绝对要避免的写法：
ORDER BY RAND()。在MySQL中，这会为每一行生成一个随机数再进行排序，CPU使用率瞬间拉满。
聚合函数 + 窗口函数混用时，NULL 和空分区行为不一致
这是报表核对时最容易漏掉的细节。SUM(sales) OVER (PARTITION BY region)，如果某个region的所有sales都是NULL，窗口函数会返回NULL；但在GROUP BY region的分组聚合下，同组的SUM()默认会返回0（除非组内所有值都是NULL）。这种语义上的差异，稍不注意就会导致数据对不上。
还有几个容易踩的坑：
A VG()窗口函数会自动忽略NULL值，但COUNT(*)不会。所以，在窗口函数的语境下，A VG(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，再确认分区字段的选择性是否足够——这两处要是没调好，加再多的索引也是徒劳。
