窗口函数在大表上慢的根本原因是执行路径未对齐数据物理分布，需通过严格匹配PARTITION BY和ORDER BY列顺序的联合索引、时间分区表+局部索引、中间结果物化等手段优化。
窗口函数在大表上慢，不是语法问题，而是执行路径没对齐数据物理分布。 直接加索引或改写 OVER 子句往往无效，关键得让 PostgreSQL 的执行计划避开全表扫描+内存排序这个死循环。
为什么 SUM() OVER (PARTITION BY x ORDER BY y) 在千万行上会爆内存？
根本原因是：PostgreSQL 必须为每个 PARTITION BY 组内所有行按 ORDER BY 排序，再逐行累积计算。如果分区键和排序键没被索引覆盖，就会触发全表扫描 + 外部排序（磁盘临时文件），I/O 成主导耗时。
- 执行计划里出现
Sort节点且actual time占比超 80%，基本就是这个病 -
Work_mem设置再高也没用——窗口范围越大（比如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），中间状态越难压缩 - 分区键（
PARTITION BY）和排序键（ORDER BY）不构成联合索引时，优化器无法利用已有顺序，只能硬排
必须建的索引：CREATE INDEX ON table (a, b) INCLUDE (c)
窗口函数的索引不是“有就行”，而是要严格匹配 PARTITION BY 和 ORDER BY 的列顺序，并把计算列包含进来。例如：
SELECT user_id, order_time, amount, SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) AS running_total FROM orders;
对应索引必须是：
CREATE INDEX idx_orders_user_time_amt ON orders (user_id, order_time) INCLUDE (amount);
- 列顺序不能颠倒：
user_id在前（分区键），order_time在后（排序键） -
INCLUDE后跟amount，避免回表读取——否则即使走索引，仍要随机 I/O 查原始行 - 别用
CONCURRENTLY建这个索引：窗口查询常在业务高峰期跑，建索引期间锁表风险高
当数据按时间递增写入时，优先用按月分区表 + 局部索引
如果表本身是时间序列（如订单、日志），且查询集中在最近 N 个月，单靠 B-tree 索引已不够。这时分区表能直接跳过无关数据块：
CREATE TABLE orders ( order_id BIGSERIAL, user_id BIGINT, order_time TIMESTAMPTZ NOT NULL, amount NUMERIC(12,2) ) PARTITION BY RANGE (order_time);
- 每个子分区（如
orders_2026_07）单独建本地索引：CREATE INDEX ON orders_2026_07 (user_id, order_time) INCLUDE (amount) - 查询带
WHERE order_time >= '2026-07-01'时，优化器自动裁剪，只扫描 1–2 个分区，而非整个十亿行父表 - 注意：分区键必须是
order_time，不能是date_trunc('month', order_time)—— 表达式分区无法触发裁剪
复杂窗口组合查询先落地再计算
当同时用 RANK()、LAG()、SUM() OVER 多个窗口函数，且涉及多层嵌套或 CTE 时，PostgreSQL 容易重复扫描同一张大表。此时不如分步：
- 用
CREATE TEMP TABLE AS SELECT ...把中间结果固化，加上合适索引 - 在 temp 表上跑窗口逻辑，避免每次执行都重算聚合路径
- temp 表生命周期短，但能绕过优化器对复杂 CTE 的保守估计（尤其 PG 15 对多层 CTE 的物化策略仍不稳定）
真正卡住性能的，往往不是窗口函数本身，而是它被迫在没有物理顺序保障的数据集上强行构造逻辑顺序。索引结构、分区策略、执行路径三者必须咬合，缺一不可。
