窗口函数慢八成是work_mem不足、索引错位或帧范围失控；应通过EXPLAIN检查Sort Method是否为external merge Disk，或查pg_stat_progress_sort.sort_bytes是否远超work_mem值。
PostgreSQL 16 窗口函数慢，八成不是 SQL 写得不对，而是 work_mem 不够、索引没对上、或窗口范围失控——调大内存、建对索引、缩窄帧范围，三招就能从分钟级降到毫秒级。
怎么确认是 work_mem 不足导致窗口变慢
窗口函数依赖内存排序，一旦超限就会写临时文件，性能断崖下跌。别猜，直接看执行计划：
- 运行
EXPLAIN (ANALYZE, BUFFERS)，重点找WindowAgg或Sort节点里是否出现Sort Method: external merge Disk - 查系统视图：
SELECT sort_bytes FROM pg_stat_progress_sort WHERE pid = <your_query_pid></your_query_pid>，如果值远超当前work_mem（比如sort_bytes是 256MB，但work_mem只设了 4MB），就是落盘了 -
pg_stat_progress_sort对窗口函数有效，但pg_stat_progress_hash没用——窗口不走哈希聚合
为什么复合索引必须按 PARTITION BY + ORDER BY 顺序建
PostgreSQL 在执行 OVER (PARTITION BY a ORDER BY b) 时，会尝试用索引跳过排序和分区定位。但索引列顺序错一点，效果就归零：
- 正确索引：
CREATE INDEX idx_user_time ON orders (user_id, order_date) INCLUDE (amount);→ 能支撑PARTITION BY user_id ORDER BY order_date - 错误做法：只建
(user_id)单列索引，或顺序颠倒为(order_date, user_id)→ 数据库仍需全表扫描 + 二次排序 - 表达式分区（如
PARTITION BY date_trunc('month', occurred_at)）必须配函数索引，否则索引失效 - 分区键基数太高（比如每行
user_id都唯一），会导致上万个分区各自排序，内存压力乘数级放大
哪些窗口帧定义容易引发性能雪崩
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 看似简洁，实则是最危险的默认帧——它强制数据库为每一行维护一个不断增长的累积状态：
- 无法并行处理，CPU 和内存随分区行数线性上涨
- 若
ORDER BY字段无索引，排序成本叠加帧计算成本，1000万行可能耗时超两分钟 - 替代方案优先选明确边界：
ROWS BETWEEN 10 PRECEDING AND CURRENT ROW（移动平均）、RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（仅当业务真需要全累计且数据稀疏时才考虑） - 纯排名需求（如分页去重）慎用
ROW_NUMBER()全量排序，可改用主键范围扫描 +LIMIT/OFFSET或游标分页
在应用里安全调高 work_mem 的实操要点
全局改 postgresql.conf 是陷阱——报表查询需要 64MB，OLTP 事务可能 2MB 就够，混在一起必然拖垮整体吞吐：
- 推荐方式：在业务代码中对单条查询显式设置会话级参数，
BEGIN; SET LOCAL work_mem = '64MB'; SELECT ... OVER (...); COMMIT; - 用连接池（如 PgBouncer）时，确认配置项
ignore_startup_parameters = work_mem已开启，否则SET命令会被静默过滤 - 并发控制：假设一条查询启动 4 路并行排序，
work_mem = '64MB'理论峰值内存 ≈ 256MB；10 个并发就接近 2.5GB，必须结合物理内存和max_connections综合评估 - 估算下限参考：单分区 10 万行 × 每行排序键约 32 字节 × 1.5 倍开销 ≈ 4.8MB —— 这是你该分区的保底
work_mem
真正卡住性能的，往往不是语法本身，而是 work_mem 和索引之间那几字节的错位，或者一不留神用了 UNBOUNDED PRECEDING 却没意识到它在百万行上要逐行累积——这些细节不盯住，再新的 PostgreSQL 16 也跑不快。
