PostgreSQL窗口函数本身不直接走索引，其性能依赖优化器能否将PARTITION BY和ORDER BY下推至扫描阶段；若WindowAgg下为Seq Scan或带Sort的Index Scan，说明优化器放弃流式处理，转而全量读取+排序，根本原因是联合索引字段顺序未严格匹配窗口逻辑、WHERE条件破坏前缀匹配或统计信息过期。
为什么WindowAgg节点下还是Seq Scan？
不是索引没建，而是索引没被用上。PostgreSQL窗口函数本身不直接“走索引”，它依赖优化器能否把 PARTITION BY 和 ORDER BY 的顺序需求下推到扫描阶段。如果执行计划里 WindowAgg 下挂的是 Seq Scan 或带 Sort 节点的 Index Scan，说明优化器放弃了流式处理，转而全量读取+内存/磁盘排序。
- 检查
EXPLAIN (ANALYZE, BUFFERS)输出中，WindowAgg上游是否出现Sort Method: external merge Disk—— 这是索引失效的典型副产品 - 确认
PARTITION BY和ORDER BY字段在联合索引中严格按顺序出现，且没有中间插入无关列（例如PARTITION BY user_id ORDER BY created_at必须对应(user_id, created_at)，不能是(created_at, user_id)） - 如果
WHERE条件用了未包含在索引前缀里的字段（比如WHERE status = 'paid'），优化器可能弃用该索引，改走全表扫描
CREATE INDEX 语句怎么写才真正生效？
窗口函数的索引不是“有就行”，而是必须满足物理顺序对齐。一个 INCLUDE 列漏掉、顺序颠倒、甚至多加一个无关列，都会让优化器绕过它。
- 基础模板：
CREATE INDEX idx_t_a_b ON t (a, b) INCLUDE (c, d);，其中a是PARTITION BY字段，b是ORDER BY字段，c、d是SELECT中直接引用的其他列（避免回表） - 别建单列索引：
CREATE INDEX ON t (a);或CREATE INDEX ON t (b);对窗口性能基本无效 - 慎用
CONCURRENTLY：建索引期间无法中断，若业务高峰期执行，可能锁表或拖慢查询；优先选低峰期非并发创建 - 函数索引要显式匹配：
PARTITION BY date_trunc('month', created_at)必须配CREATE INDEX ON t (date_trunc('month', created_at));
WHERE 条件一加，索引就消失了？
高频过滤字段和窗口逻辑字段不协同，是索引被跳过的最常见原因。优化器不会为“先过滤再开窗”自动重写 SQL，它只看最终表达式的可下推性。
- 把过滤字段提到联合索引最左：例如常用
WHERE status = ? AND user_id = ? ORDER BY created_at，索引应为(status, user_id, created_at) INCLUDE (amount) - 用子查询隔离过滤逻辑：
SELECT * FROM (SELECT user_id, created_at, amount FROM orders WHERE status = 'shipped') t WINDOW w AS (PARTITION BY user_id ORDER BY created_at)，确保窗口计算只作用于已裁剪的数据集 - 避免在
WHERE中使用表达式或类型隐式转换（如WHERE user_id::text = '123'），这会破坏索引匹配
执行计划里出现 Materialize 或 Window Spool 怎么办？
这两个节点意味着 PostgreSQL 已放弃流式计算，被迫把中间结果暂存到内存或磁盘。这不是配置问题，而是数据访问路径断裂的明确信号。
-
Materialize出现在WindowAgg上方，通常是因为PARTITION BY字段无索引，导致必须先哈希分组再逐个计算 -
Window Spool多见于ROWS BETWEEN UNBOUNDED PRECEDING类累计计算，但前提是数据未按ORDER BY物理排列 —— 即使有索引，若扫描方式没利用其顺序，仍会触发 Spool - 验证是否真有序：运行
EXPLAIN SELECT * FROM t ORDER BY a, b LIMIT 10;，如果看到Index Scan Backward或Index Only Scan，说明索引顺序被识别；如果仍是Sort+Seq Scan，说明索引未命中或统计信息过期（记得ANALYZE t;）
实际调优时最容易被忽略的一点：窗口函数的性能瓶颈往往不在 SQL 写法本身，而在你是否意识到 —— 它对数据物理分布的依赖，比普通查询强得多。索引建得再全，只要 PARTITION BY 和 ORDER BY 不构成连续的存储顺序，优化器就只能硬排。
