窗口函数必须为partition by和order by列创建复合索引，顺序为分组键在前、排序键在后，否则触发全量排序导致性能骤降。
窗口函数的 PARTITION BY 和 ORDER BY 列必须联合建索引，否则 WindowAgg 节点大概率触发排序（Sort），性能断崖式下跌。
为什么窗口函数特别依赖复合索引
PostgreSQL 的窗口函数执行依赖数据在物理上或逻辑上已按 PARTITION BY 分组、并在组内按 ORDER BY 排序。如果没有对应索引，优化器只能退回到内存或磁盘排序 —— 即使只查 10 行，也可能因 work_mem 不足而落盘，耗时翻数倍。
常见错误现象：
-
EXPLAIN ANALYZE显示Sort节点耗时占比超 70% - 执行计划中出现
WindowAgg (cost=... rows=... width=...) (actual time=...)后紧跟Sort，而非直接接Index Scan - 加了
LIMIT也慢：因为排序必须全量完成才能取前 N 行
索引列顺序必须是 PARTITION BY 在前、ORDER BY 在后
例如查询：SELECT user_id, order_date, SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date) FROM orders;
正确索引写法：
CREATE INDEX idx_orders_user_date ON orders (user_id, order_date) INCLUDE (amount);
关键点：
-
user_id必须放第一位：它是分组键，决定数据“切片”边界；跳过它会导致索引无法用于PARTITION BY -
order_date紧随其后：确保每个user_id组内数据天然有序，省去组内排序 -
INCLUDE (amount)是加分项：若SUM(amount)是唯一需要的列，且amount不参与过滤，用INCLUDE可触发Index Only Scan，避免回表 - 不要反过来建
(order_date, user_id)：这只能加速按时间范围查，对窗口函数无效
带方向和 NULLS 处理的排序索引要显式声明
如果 ORDER BY 包含方向或 NULLS FIRST/LAST，索引必须完全匹配，否则仍会排序。
例如查询：ORDER BY created_at DESC NULLS LAST
对应索引必须写成：
CREATE INDEX idx_logs_user_created_desc_nulls_last ON logs (user_id, created_at DESC NULLS LAST);
注意：
-
DESC和NULLS LAST是索引定义的一部分，不是可选修饰；缺一不可 - 若业务中同时存在
ASC和DESC查询，优先覆盖高频方向；混合方向需单独建索引 - 默认
NULLS FIRST（B-tree 索引），但ORDER BY ... DESC默认是NULLS LAST，不显式声明极易踩坑
避免函数包裹、类型转换与低选择性列前置
窗口函数索引失效的典型原因和其他查询一样，但后果更隐蔽：
- 写成
PARTITION BY UPPER(user_id)→ 必须建函数索引：CREATE INDEX ... ON orders (UPPER(user_id), order_date); -
user_id是bigint，但查询传入字符串'123'→ 触发隐式转换，索引失效；应统一为123或显式::bigint - 把低选择性列（如
status只有 3 个值）放在PARTITION BY位置 → 分组粒度太粗，大量数据挤在同一组，排序压力反而更大；此时应检查是否真该用窗口函数，或换用GROUP BY+ 聚合 - 未运行
VACUUM ANALYZE orders→ 优化器误判数据分布，低估索引价值，主动放弃使用
真正容易被忽略的是：窗口函数索引一旦建错，EXPLAIN 很难一眼看出“本该用索引却没用”，因为它不报错，只是默默多一个 Sort 节点 —— 你得盯着 actual time 和节点顺序，而不是只看有没有 Index Scan。
