窗口函数本身不直接使用索引，因其在SELECT阶段执行，而索引仅在WHERE、JOIN、ORDER BY等前期阶段生效；但WHERE条件、PARTITION BY+ORDER BY组合列、ORDER BY顺序及函数索引可间接提升其性能。
窗口函数本身不直接使用索引，但它的执行效率可能间接受到索引影响。
窗口函数不走索引的根本原因
窗口函数是在 SQL 执行流程的较后阶段（SELECT 阶段）计算的，此时数据已经完成 FROM、JOIN、WHERE、GROUP BY 等操作。而索引主要在 WHERE、JOIN、ORDER BY 等前期阶段起作用——用于快速定位或排序行。一旦进入窗口计算环节，数据库需对已筛选/分组后的结果集按 PARTITION BY 和 ORDER BY 重新组织“窗口”，这个过程依赖内存排序或临时结构，不调用 B-tree 或哈希索引。
哪些地方能间接借力索引？
虽然 OVER() 内部不查索引，但以下环节若被优化，可显著加快窗口函数整体执行速度：
- WHERE 条件中的列有索引：更快过滤出参与窗口计算的子集；
-
PARTITION BY + ORDER BY 的组合列有复合索引：例如
OVER(PARTITION BY dept_id ORDER BY hire_date)，建索引INDEX(dept_id, hire_date)可避免排序开销； -
ORDER BY 子句匹配已有索引顺序：如
ORDER BY create_time DESC对应INDEX(create_time DESC)，可跳过排序步骤； -
聚合窗口中涉及的字段被函数索引覆盖：比如
SUM(upper(name)) OVER(...)若有INDEX(upper(name))，可能提升表达式预处理效率（但极少见，且依赖数据库支持）。
特别注意的坑
这些写法会让原本可用的索引失效，连带拖慢窗口函数性能：
- 在 PARTITION BY 或 ORDER BY 中对列使用函数，如
PARTITION BY YEAR(order_date)； - WHERE 中类型不一致，如
WHERE user_id = '123'（user_id 是 INT），导致隐式转换，索引失效； - ORDER BY 方向与索引方向相反，且数据库未支持反向扫描（如 MySQL 5.7 之前）；
- 窗口框架用了
RANGE且排序列存在大量重复值，触发全窗口扫描而非高效跳查。
验证是否受益于索引的小技巧
运行带 EXPLAIN（MySQL/PostgreSQL）或 EXECUTION PLAN（SQL Server）的查询，重点关注：
- 是否有
Using filesort或Sort操作 —— 出现说明 ORDER BY 没走索引； - 是否显示
key字段用了你建的索引； - rows 列数值是否明显小于全表行数 —— 反映 WHERE 阶段索引生效。
