windowagg节点cost高或width异常（>1000字节）是性能问题首要信号，因窗口函数需缓存整分区数据，width大加重内存与磁盘压力，cost高常反映排序或物化代价被低估。
看懂执行计划里 WindowAgg 节点的 cost 和 width
PostgreSQL 执行计划中出现 WindowAgg 节点，不等于一定慢；但它的 cost 显著高于上游节点（比如 Sort 或 Seq Scan），或 width 异常大（比如 > 1000 字节），就是性能问题的第一信号。
原因很简单：窗口函数需要缓存整个分区的数据才能计算，width 大意味着每行要暂存更多字段，内存压力和磁盘溢出风险直线上升；cost 高往往反映排序开销或物化代价被低估。
-
EXPLAIN (ANALYZE, BUFFERS)必须加，光看EXPLAIN的预估 cost 容易误判 - 关注
WindowAgg节点的Actual Total Time和Buffers: shared hit/read，读盘多说明 work_mem 不够，触发了临时文件 - 如果
width比输入行宽翻倍以上，检查是否无意把大字段（如jsonb、text）拖进了SELECT或PARTITION BY
OVER () 无分区无排序时，为什么还走排序？
即使写的是 OVER ()（全表一个分区，无 ORDER BY），PostgreSQL 仍可能插入 Sort 节点——这不是 bug，是为保证语义正确性：SQL 标准要求窗口函数结果具有确定性，而堆表扫描顺序不保证稳定。
这会导致本可避免的排序开销，尤其在大表上明显。
- 确认是否真不需要顺序：如果业务能接受任意但稳定的输出（比如只取
COUNT(*) OVER()），可加ORDER BY ctid显式锚定物理顺序，有时能跳过额外排序 - 用
CLUSTER或CREATE INDEX ... ORDER BY让数据物理有序，让优化器感知到“已排序”，可能消除Sort - 避免在
SELECT中混用确定性/非确定性窗口函数（如同时用ROW_NUMBER() OVER ()和AVG(x) OVER ()），前者强制排序，后者其实不需要
分区键（PARTITION BY）字段没索引，执行计划会怎样？
没有索引的 PARTITION BY 字段，PostgreSQL 无法流式处理窗口；它必须先把所有数据读入内存（或临时文件），按分区键哈希或排序分组，再逐一分区计算——这就是最典型的内存爆涨和临时文件生成场景。
现象包括：WindowAgg 节点下挂一个巨大的 Sort 或 HashAggregate，Buffers: shared read 猛增，查询卡在 “Writing to disk” 阶段。
- 对高频使用的
PARTITION BY字段（如user_id,tenant_id）建 B-tree 索引，哪怕只是单字段，也能让优化器选择 merge-join-friendly 的执行路径 - 如果分区键是表达式（如
PARTITION BY date_trunc('month', created_at)），考虑建函数索引：CREATE INDEX idx_orders_month ON orders (date_trunc('month', created_at)) - 别依赖
work_mem硬扛：设太高可能挤占并发查询内存，设太低直接写磁盘；索引才是治本
RANGE vs ROWS 框架对执行计划的影响
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是安全的流式计算模式，优化器通常能用累积算法，内存占用恒定；而 RANGE（尤其是带 VALUE PRECEDING/FOLLOWING）大概率触发全分区排序+二分查找，执行计划里会出现 Materialize + Sort 嵌套，且 cost 预估常严重偏低。
- 除非业务逻辑明确需要基于值的滑动（如“过去7天销售额”），否则优先用
ROWS框架 -
RANGE在时间字段上容易因精度问题（timestampvstimestamptz、时区隐式转换）导致意外的分区行为，执行计划看不出，但结果错 - 用
EXPLAIN (ANALYZE)对比两种框架的Actual Rows和Actual Total Time，差距常达 3–10 倍
真正卡住性能的，往往不是窗口函数本身，而是它暴露出来的底层数据分布缺陷：缺失索引、宽字段滥用、物理无序、框架误选。执行计划里每个节点都不是孤立的，WindowAgg 只是最后一环的显影剂。
