WindowAgg后出现Materialize或Spool，说明PostgreSQL无法流式计算窗口函数，根本原因是基表缺少PARTITION BY与ORDER BY字段的联合索引及work_mem不足。
WindowAgg 节点后面跟着 Materialize 或 Window Spool，说明视图底层的窗口函数没走流式计算——这不是 SQL 写得错，而是 PostgreSQL 缺少匹配的物理排序能力。优化核心就两条：让数据按 PARTITION BY + ORDER BY 顺序落盘，再控制窗口计算的内存开销。
为什么视图里的窗口函数比普通查询更难优化？
视图本身不存储数据、不预编译、不缓存执行计划；每次调用都重新解析+重生成计划。一旦视图定义里含 SUM() OVER (PARTITION BY user_id ORDER BY order_date) 这类结构，且底层表没对应索引，PostgreSQL 就只能退回到全表扫描 + 全局排序 + Materialize 中间结果。
- 视图无法“自带”索引，索引必须建在基表上
- 如果视图用了
WITH CHECK OPTION或嵌套了多层 CTE，优化器可能放弃下推WHERE过滤，导致窗口计算作用于全量数据 -
pg_stat_statements统计的是视图展开后的最终 SQL，但你查不到“这个视图用了哪个索引”，只能靠EXPLAIN ANALYZE实测
必须建的联合索引：列序不能颠倒
错误写法：CREATE INDEX ON orders(order_date, user_id) 或单列索引——它无法支撑 PARTITION BY user_id ORDER BY order_date 的流式分组排序。
- 第一列必须是
PARTITION BY字段（如user_id），确保相同分区的数据物理连续 - 第二列必须是
ORDER BY字段（如order_date），保证每个分区内已有序 - 用
INCLUDE把窗口函数中引用的其他列（如amount）带上，触发Index Only Scan，避免回表
正确示例：CREATE INDEX orders_user_date_idx ON orders(user_id, order_date) INCLUDE (amount);
work_mem 不够时，视图会悄悄变慢
视图里多个窗口函数（比如同时用 ROW_NUMBER()、SUM() OVER、LAG()）会启动多个独立排序操作，每份都吃一份 work_mem。全局设高会拖垮 OLTP 查询，但视图调用又常来自报表场景。
- 在应用端执行视图前加：
BEGIN; SET LOCAL work_mem = '64MB'; SELECT * FROM my_analytic_view; COMMIT; - 确认连接池（如 PgBouncer）允许
SET命令，否则需配ignore_startup_parameters = work_mem - 用
EXPLAIN (ANALYZE, BUFFERS)看Sort Method: external merge Disk—— 出现就说明已落盘，必须调大
WHERE 条件别被视图“吞掉”
即使建好了 user_id, order_date 联合索引，如果视图调用时带 WHERE status = 'shipped'，而 status 不在索引里，优化器大概率放弃走索引，退回 Seq Scan。
- 高频过滤字段要前置进索引，例如：
CREATE INDEX orders_status_user_date_idx ON orders(status, user_id, order_date) INCLUDE (amount) - 或改用子查询封装：
SELECT * FROM (SELECT ... FROM orders WHERE status = 'shipped') t WINDOW w AS (PARTITION BY user_id ORDER BY order_date)，把过滤提前到窗口之前 - 避免在视图定义里写
WHERE—— 把过滤逻辑留给调用方，保持视图通用性
视图不是性能黑盒，它的瓶颈完全暴露在基表索引结构和运行时内存配置里。最容易被忽略的是：你以为加了索引就万事大吉，但只要 WHERE 条件里出现一个未索引字段，或者 work_mem 没临时调高，WindowAgg 就会立刻切回磁盘模式——而这个切换在视图调用时完全静默，只在 EXPLAIN ANALYZE 里露馅。
