窗口函数慢主因是分区设计不合理，需优化分区键选择、添加联合索引、前置过滤条件，并评估是否可用聚合+JOIN替代。

窗口函数慢，多数不是函数本身的问题，而是分区（PARTITION BY）设计不合理导致的数据倾斜或重复扫描。优化核心在于减少每个分区的数据量、避免全表排序、控制分区粒度。

检查分区键是否引入高基数或低选择性字段

比如用 user_id 分区但该字段有上千万唯一值，又没索引支撑，会导致大量小分区反复初始化上下文，CPU 和内存开销陡增。同样，用 create_date（仅年月日）分区可能合并了几十万行，排序压力集中。

• 优先选业务语义明确、基数适中（几千到几万）、且已有索引的字段，如 region_id、product_category
• 避免直接用 id、uuid、timestamp（毫秒级）等超高基数列做分区键
• 可临时加复合分区，例如 PARTITION BY region_id, EXTRACT(YEAR FROM order_time)，分散压力

确保 ORDER BY 子句有对应索引

窗口函数中带 ORDER BY（如 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)）时，数据库通常需对每个分区单独排序。若 y 列无索引，就会触发磁盘排序或大量内存排序。

• 为 (partition_col, order_col) 建联合索引，顺序必须一致
• 例如：CREATE INDEX idx_region_order ON sales(region_id, sale_amount DESC);
• 注意：部分数据库（如 PostgreSQL）支持索引下推排序，MySQL 8.0+ 对覆盖索引也更友好

用条件过滤前置，别让窗口函数扫全量数据

常见错误是先写窗口函数，再用外层 WHERE 过滤——此时窗口计算已在全表/大结果集上完成，浪费严重。

• 把时间范围、状态码、业务标识等强过滤条件放在子查询或 CTE 最内层
• 示例：先 SELECT ... FROM orders WHERE order_date >= '2024-01-01'，再在其上套窗口逻辑
• 必要时拆分：用临时表或物化 CTE 缓存过滤后的小结果集，再对其跑窗口函数

评估是否真需要窗口函数，或可用聚合+JOIN 替代

某些场景（如“每个用户最新一笔订单”）看似要 ROW_NUMBER()，但实际可通过 GROUP BY + JOIN 或 LATERAL 更高效实现，尤其当分区数据不均衡时。

• 用 SELECT * FROM t1 JOIN (SELECT user_id, MAX(create_time) AS max_t FROM t1 GROUP BY user_id) t2 ON ... 可绕过窗口排序开销
• PostgreSQL 支持 LATERAL，MySQL 8.0+ 支持 ROW_NUMBER() 但对大分区仍建议压测对比
• 如果只取 Top-N，考虑 QUALIFY（Snowflake/BigQuery）或 LIMIT 配合子查询，避免计算全部排名