WindowAgg后出现Materialize或Spool，是因为PostgreSQL无法流式计算窗口函数，必须将中间结果写入临时空间；根本原因在于PARTITION BY和ORDER BY列缺乏匹配的联合索引，导致全表扫描、排序无法下推或窗口帧过大触发缓冲溢出。
为什么WindowAgg后面总跟着Materialize或Spool？
这不是你写错了，而是PostgreSQL在执行窗口函数时，发现无法按需流式计算，被迫把中间结果先写到临时空间（内存或磁盘）——这个动作在执行计划里就叫 Materialize 或 Window Spool。常见触发条件有三个：
• PARTITION BY 列没索引，导致必须全表扫描后才能分组
• ORDER BY 列未与分区列构成联合顺序，排序无法下推到索引扫描
• 窗口帧范围过大（如 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），但数据未按该顺序物理存储
CREATE INDEX 必须覆盖 PARTITION BY + ORDER BY
窗口函数的执行效率极度依赖底层数据的物理排列顺序。PostgreSQL不会为每个查询动态重排数据，它只信任索引定义的顺序。
• 错误写法：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)
• 关键点：第一列必须是 PARTITION BY 字段，第二列必须是 ORDER BY 字段；INCLUDE 后跟 SELECT 中用到的其他列，避免回表
避免在窗口函数中混用非索引字段过滤
即使建好了 user_id, order_date 联合索引，如果 WHERE 条件里用了未索引字段（比如 WHERE status = 'shipped'），优化器可能放弃走索引，退回到 Seq Scan + WindowAgg 全量排序。
• 检查方式：运行 EXPLAIN (ANALYZE, BUFFERS) SELECT ... OVER (PARTITION BY user_id ORDER BY order_date)，看是否出现 Seq Scan 或高 Shared Read 值
• 解决方案：
• 把高频过滤字段加入联合索引前缀，例如 CREATE INDEX orders_status_user_date_idx ON orders(status, user_id, order_date) INCLUDE (amount)
• 或者用子查询/CTE 先过滤再开窗，确保窗口计算只作用于目标数据集
慎用 RANGE 和复杂 FRAME 定义
RANGE BETWEEN（基于值范围）比 ROWS BETWEEN（基于行号）更容易触发 Spool，尤其当 ORDER BY 列存在大量重复值时，PostgreSQL必须缓冲所有“同值”行才能确定窗口边界。
• 示例陷阱：OVER (PARTITION BY user_id ORDER BY created_date RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW)
• 更稳的选择：OVER (PARTITION BY user_id ORDER BY id ROWS BETWEEN 100 PRECEDING AND CURRENT ROW)（前提是 id 是递增主键且能代表时间序）
• 如果必须用时间范围，考虑预计算时间分桶（如 date_trunc('day', created_date)）并建立对应索引，把 RANGE 转为 ROWS 场景
WindowAgg 的 cost 从百万级降到千级，往往不是改 SQL，而是补对了那一行 CREATE INDEX。最容易被忽略的是：索引列顺序必须严格匹配窗口子句中的 PARTITION BY 和 ORDER BY 顺序，差一个位置，就等于没建。 
