窗口函数执行慢主因常是PARTITION BY字段无索引，导致排序无法下推而触发磁盘排序或内存膨胀；需建严格匹配的复合索引，并验证执行计划是否消除Using filesort。
窗口函数执行慢，是不是因为没走索引？
不是所有窗口函数都能用上索引，但 PARTITION BY 字段如果没索引，基本等于放弃优化机会。数据库在计算 ROW_NUMBER()、RANK() 或 AVG() OVER (PARTITION BY ...) 时，会先按 PARTITION BY 分组排序——这个过程若无法利用索引完成排序，就会触发磁盘临时表或大量内存排序，数据量一过千万，耗时直接从毫秒跳到秒级。
实操建议：
- 检查执行计划中是否出现
Using filesort或Using temporary；有则大概率是PARTITION BY字段缺失索引 -
PARTITION BY字段必须是查询条件中高频、高区分度的列（如user_id、tenant_id、date_id），低区分度字段（如status只有 0/1）建索引意义不大 - 复合索引要严格匹配：若窗口写的是
PARTITION BY dept_id, team_id ORDER BY create_time，索引应为(dept_id, team_id, create_time)，顺序不能错
为什么加了索引还是慢？常见陷阱在这儿
索引建了，执行计划也显示走了索引，但窗口函数仍卡顿——大概率掉进了“覆盖不全”或“统计信息陈旧”的坑。
典型现象：
- 执行计划里
key_len明显小于预期（比如索引定义是 3 列，但只用了前 2 列），说明ORDER BY部分没被覆盖，仍需额外排序 - 表数据更新频繁但
ANALYZE TABLE没跑过，优化器误判行数，选错执行路径 - 窗口函数嵌套太深，比如
ROW_NUMBER() OVER (PARTITION BY a ORDER BY b) AS rn再套一层WHERE rn = 1，MySQL 8.0+ 虽支持下推，但老版本或某些引擎会强制物化中间结果
验证方式：对目标表手动执行 ANALYZE TABLE orders;，再看执行计划变化；如仍无效，尝试把窗口逻辑拆成临时表 + 索引分步处理。
大数据量下，替代窗口函数的轻量方案
当单次窗口计算涉及亿级数据且实时性要求不高时，硬扛 OVER 不如换思路。窗口函数本质是“分组内有序计算”，很多场景可用更可控的方式替代。
可选路径：
- 用
JOIN+ 聚合子查询模拟：例如取每个user_id最新订单，改写为SELECT o.* FROM orders o JOIN (SELECT user_id, MAX(create_time) AS max_t FROM orders GROUP BY user_id) t ON o.user_id = t.user_id AND o.create_time = t.max_t - 业务层分页预计算：对固定维度（如每日活跃用户排行榜），提前用定时任务算好结果存入宽表，查时直取
- 启用物化视图（PostgreSQL 9.4+ / Oracle / SQL Server 2022+）或使用
MATERIALIZED VIEW缓存窗口结果，避免每次重算
注意：这些方案牺牲了“绝对实时”，但换来的是可预测的响应时间和资源占用，对报表、后台任务等场景更稳妥。
MaxCompute 或 Hive 上窗口函数卡顿怎么调？
云数仓环境里，窗口函数慢往往不是 SQL 本身问题，而是并行度配置失当或数据倾斜导致单个 instance 负载过高。
关键动作：
- 检查
PARTITION BY字段是否造成严重倾斜（比如 90% 数据落在tenant_id = 'default'），用COUNT(*) GROUP BY tenant_id快速验证 - 避免
PARTITION BY常量（如PARTITION BY 1）或DISTRIBUTE BY常量，这会强制所有数据进同一个 instance - 在 MaxCompute 中，通过
set odps.sql.groupby.skewindata=true;启用倾斜处理；Hive 可设hive.groupby.skewindata=true - 必要时加
DISTRIBUTE BY+SORT BY手动控制分发与局部排序，比全靠OVER更可控
真正棘手的不是语法写不对，而是没意识到窗口函数在分布式环境下天然依赖数据分布质量——字段值越均匀，并行效果越好；一旦倾斜，优化器再聪明也救不了单点瓶颈。
