窗口函数必须在JOIN前执行，作用于原始事实表而非宽表；先过滤、再开窗、最后JOIN补维度，确保PARTITION BY字段有联合索引且ORDER BY确定性，避免数据膨胀与磁盘排序。
JOIN本身不优化窗口函数，反而是错误的JOIN顺序会拖垮窗口性能；真正起作用的是让窗口计算在最小、最干净的数据集上执行，再用JOIN补全维度信息。
先窗口后JOIN：避免数据膨胀干扰分组逻辑
窗口函数必须作用于原始事实表（比如orders），而不是JOIN后的宽表。一旦先JOIN再开窗，维度表的冗余行（如用户历史昵称、地址变更记录）会导致PARTITION BY user_id分组错乱，甚至生成重复序号。
- 错误写法：
SELECT *, ROW_NUMBER() OVER (PARTITION BY u.city) FROM orders o JOIN users u ON o.user_id = u.id—— 若一个用户有多条users记录，o行会被复制，ROW_NUMBER()就不是按订单分组，而是按“订单+用户快照”组合分组 - 正确路径：用CTE或子查询先在
orders上完成ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，再LEFT JOIN users补字段 - PostgreSQL中可进一步用
DISTINCT ON (user_id) ORDER BY user_id, created_at DESC替代窗口，但仅适用于单排序字段且需确保索引覆盖
PARTITION BY字段必须来自JOIN结果且有联合索引
窗口的PARTITION BY和ORDER BY字段，必须同时出现在JOIN后的SELECT列表中，并且底层存储顺序要匹配——否则PostgreSQL无法流式计算，必然触发Window Spool或Materialize落盘。
- 假设你最终要按
users.city分组排名，那JOIN必须是INNER JOIN或LEFT JOIN后用COALESCE(u.city, 'unknown')兜底，且u.city必须出现在SELECT里 - 索引不能只建
CREATE INDEX ON users(city)，而应建联合索引：CREATE INDEX idx_users_city_id ON users(city, id) INCLUDE (nickname)，确保PARTITION BY u.city ORDER BY u.id能走索引扫描 - 如果
ORDER BY用的是orders.created_at，但PARTITION BY是users.city，这种跨表排序无法下推，必然全量排序——此时应改用PARTITION BY o.user_id再关联城市，而非强行跨表分组
WHERE过滤必须在窗口前完成，别让无关数据进窗口
窗口函数对每一分区都要做独立排序，若WHERE条件放在窗口之后（比如外层WHERE status = 'paid'），PostgreSQL可能放弃已建的联合索引，退回到Seq Scan再WindowAgg，导致10倍以上性能下降。
- 安全做法：用CTE先过滤，再开窗：
WITH paid_orders AS ( SELECT * FROM orders WHERE status = 'paid' ) SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM paid_orders;
- 检查执行计划是否出现
Sort Method: external merge Disk，一旦看到Disk，说明work_mem不足或数据未提前过滤 - 高频过滤字段（如
status、tenant_id）应前置到联合索引最左侧，例如：CREATE INDEX idx_orders_status_user_date ON orders(status, user_id, created_at) INCLUDE (amount)
慎用RANGE帧，优先用ROWS + 确定性排序
RANGE BETWEEN依赖值语义，在ORDER BY列存在大量重复时（比如按天截断的DATE(created_at)），PostgreSQL必须缓冲所有同值行才能确定窗口边界，极易触发内存溢出；而ROWS BETWEEN只数行号，稳定可控。
- 避免：
SUM(amount) OVER (PARTITION BY user_id ORDER BY DATE(created_at) RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW) - 改用：
SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，并确保(user_id, created_at)有索引 - 所有
ORDER BY字段必须带确定性后缀，例如ORDER BY created_at DESC, id DESC，否则ROW_NUMBER()在时间相同时结果不可复现
最容易被忽略的一点：窗口函数的性能瓶颈往往不在SQL写法本身，而在索引是否严格匹配PARTITION BY + ORDER BY的顺序，以及WHERE是否在窗口前收缩了数据集——这两项没做到，加再多work_mem也救不回磁盘排序。
