窗口函数慢主因是分区设计不合理，需优化分区键选择、添加联合索引、前置过滤条件，并评估是否可用聚合+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配合子查询，避免计算全部排名
