窗口函数性能瓶颈主要体现在Sort、WindowAgg和Materialize节点：Sort因ORDER BY触发落盘，WindowAgg的width大或temp读写多表明内存不足，Materialize反映中间结果缓存压力；PARTITION BY无匹配复合索引时易现Seq Scan+Sort组合，需建(PARTITION BY, ORDER BY)顺序索引。
窗口函数本身不改变行数，但执行计划里看不到“窗口函数”字样——它被拆解成排序、分组、聚合等底层操作。真正影响性能的，是 PARTITION BY 和 ORDER BY 引发的排序与内存开销。
EXPLAIN 输出中如何识别窗口函数的开销点
窗口函数不会单独作为一个节点出现在执行计划里。它的代价分散在几个关键操作中：
-
Sort节点：只要用了ORDER BY（哪怕只在OVER()里），就大概率出现；若数据量大且没索引支撑，这里会吃掉大量内存甚至落盘 -
GroupAggregate或WindowAgg（PostgreSQL）：表示正在做窗口聚合；注意看Buffers字段，高shared hit是好事，但频繁temp read/write就说明内存不足、被迫用磁盘 -
Materialize：优化器为复用中间结果而缓存数据，常见于嵌套窗口或多次引用同一 CTE；它本身不慢，但会显著增加内存压力
PARTITION BY 没走索引时的典型表现
当 PARTITION BY 列没有合适索引，又配合 ORDER BY，执行计划常出现 Sort + Seq Scan 组合，而不是 Index Scan + Sort：
- 例如：
SELECT user_id, event_time, SUM(amount) OVER (PARTITION BY user_id ORDER BY event_time)，若user_id上无索引，数据库只能全表扫描再排序 - 即使
user_id有单列索引，但ORDER BY event_time不在索引中，仍可能触发额外排序 - 解决办法不是加单列索引，而是建复合索引：
CREATE INDEX idx_user_event ON events (user_id, event_time)
ROWS BETWEEN 导致的意外性能拐点
ROWS BETWEEN 看似只是限定范围，但它直接影响窗口计算是否能流式处理：
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：可增量计算，内存友好 -
ROWS BETWEEN 10 PRECEDING AND 10 FOLLOWING：必须缓存至少 21 行，对高并发小窗口查询影响不大，但在千万级结果集上会显著抬高work_mem消耗 -
RANGE BETWEEN更危险：它按值而非行号取范围，可能隐式触发重复排序或全分区扫描（尤其当排序列存在大量重复值时）
为什么 ANALYZE 选项比纯 EXPLAIN 更重要
只看 EXPLAIN 容易误判——优化器估算的 cost 常严重偏离真实情况。必须加 ANALYZE 才能看到实际行为：
-
EXPLAIN (ANALYZE, BUFFERS) SELECT ...会显示真实执行时间、是否发生磁盘溢出（temp read）、缓存命中率 - 特别注意
Actual Total Time和Planning Time的比值：如果 Planning Time 占比异常高（>10%），说明优化器在多个窗口路径间反复权衡，可能因统计信息过期或列相关性未收集导致 - 别忽略
Buffers: shared hit=xxx read=yyy—— 高read值往往意味着物理 I/O 已成瓶颈，此时调优重点应转向减少数据扫描量，而非改写窗口逻辑
窗口函数的执行计划不像 JOIN 或 WHERE 那样有明确“坏节点”，它的性能陷阱藏在排序稳定性、内存边界和索引覆盖的缝隙里。最常被忽略的是：你以为在优化 SQL，其实是在和优化器争夺 work_mem 和统计信息的控制权。
