窗口函数性能瓶颈首要排查WindowAgg节点，若其位于执行计划顶部、Actual Total Time占比超70%或width>1000字节，即为关键瓶颈；需结合Buffers读盘情况、Sort Method是否external merge Disk、是否存在Materialize/Spool节点，并检查PARTITION BY与ORDER BY字段是否建有匹配复合索引及work_mem是否充足。
看执行计划里有没有 WindowAgg 节点
窗口函数慢，第一眼就该盯住 EXPLAIN (ANALYZE, BUFFERS) 输出里是否出现 WindowAgg 节点——它不是装饰，而是实际执行窗口计算的物理算子。如果它出现在执行计划顶部、Actual Total Time 占比超 70%，或 width > 1000 字节，基本可以锁定瓶颈就在这儿。
常见误判：看到 Sort 节点就以为是排序慢，其实它常是 WindowAgg 的前置依赖；真正耗时的是后面那个 WindowAgg 自己缓存、物化、逐行计算的过程。
- 重点检查
Buffers: shared read是否远高于shared hit，读盘多说明内存不够，触发了临时文件 - 留意
Sort Method: external merge Disk—— 这是work_mem不足的明确信号，不是索引问题 - 如果
WindowAgg下挂了Materialize或Window Spool，说明 PostgreSQL 无法流式计算，被迫落盘
查 PARTITION BY 和 ORDER BY 字段有没有联合索引
没有匹配的复合索引，WindowAgg 就只能全表扫描 + 内存哈希分组或强制排序，性能断崖下跌。单列索引（比如只建 user_id 或只建 order_date）完全没用。
正确索引必须满足：第一列 = PARTITION BY 字段，第二列 = ORDER BY 字段，后续 INCLUDE 所有 SELECT 中用到的非分区/排序列。
- 错误写法：
CREATE INDEX ON orders(user_id)或CREATE INDEX ON orders(order_date) - 正确写法：
CREATE INDEX orders_user_date_idx ON orders(user_id, order_date) INCLUDE (amount) - 如果 WHERE 条件高频过滤
status，得把status提前：CREATE INDEX orders_status_user_date_idx ON orders(status, user_id, order_date) INCLUDE (amount) - 别在
PARTITION BY里用表达式（如date_trunc('month', created_at)），除非你建了函数索引
确认是否被无关数据拖累
窗口函数不会自动下推 WHERE 条件。哪怕加了完美索引，只要 WHERE 里用了未索引字段（比如 WHERE status = 'shipped'），优化器可能直接放弃走索引，退回到 Seq Scan + WindowAgg 全量处理。
- 运行
EXPLAIN (ANALYZE, BUFFERS)，看最上层是不是Seq Scan，且Rows Removed by Filter数值巨大 - 解决方案优先用子查询或 CTE 先过滤：
WITH filtered AS (SELECT * FROM orders WHERE status = 'shipped') SELECT ... FROM filtered OVER (...) - 避免在窗口函数中混用确定性与非确定性函数（如同时用
ROW_NUMBER() OVER ()和AVG(x) OVER ()），前者会强制全局排序，后者其实不需要 - 如果业务允许，
OVER ()全表无分区时，可加ORDER BY ctid显式锚定物理顺序，有时能跳过额外Sort节点
检查 work_mem 是否够用
窗口函数内部排序极度依赖 work_mem。每个分区都要独立排序，分区数越多，内存压力越呈乘数级增长。一看到 external merge Disk 或 pg_stat_progress_sort.sort_bytes > work_mem，就是它了。
- 别改全局
postgresql.conf—— OLTP 查询会被连带拖慢 - 安全做法是在应用中对目标查询显式设置：
BEGIN; SET LOCAL work_mem = '64MB'; SELECT ...; COMMIT; - 起始值建议从
'16MB'测起，逐步试'32MB'、'64MB'；超过'128MB'要评估并发压力 - 估算下限参考：单分区平均 10 万行 × 每行排序键约 32 字节 × 1.5 开销 ≈ 4.8MB，这就是该分区排序的保底需求
真正卡住的点往往不在语法，而在物理数据排列和内存资源之间那层薄薄的错配——索引没对齐、work_mem 没喂够、或者 WHERE 条件悄悄绕开了索引。这些细节不显眼，但每一条都足以让窗口函数从秒级退化到分钟级。
