多个OVER子句性能瓶颈源于重复排序，关键在索引设计：需将所有PARTITION BY、ORDER BY及WHERE字段按规则组合为单个复合索引，并确保方向一致、顺序合理。
多个 OVER 子句本身不直接导致性能爆炸，但它们极易触发重复排序、索引失效和隐式全表扫描——问题不在“用了几个”，而在“每个怎么写的”。
为什么加了索引，多个OVER还是慢
SQL Server 无法复用不同 ORDER BY 或不同 PARTITION BY 的排序结果。比如同时存在：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY hire_date DESC)<br>SUM(salary) OVER (PARTITION BY region ORDER BY created_at)
这两个窗口函数会各自走一遍排序流程，哪怕字段都有索引。常见错误现象：
- 执行计划里出现多个
Sort算子（尤其带Warning: No Join Predicate） -
Actual Number of Rows比预估大数倍，说明优化器误判了数据分布 - 即使加了
(dept, hire_date DESC)索引，第二个region窗口仍回表或走聚集索引扫描
如何设计索引让多个OVER共用一个排序路径
核心原则：合并所有 PARTITION BY 和 ORDER BY 字段到一个复合索引中，并按优先级排序。
索引字段顺序必须满足：
- 所有
PARTITION BY字段放最左（按任意顺序均可，但建议高频过滤字段靠前） - 所有
ORDER BY字段紧随其后，方向（ASC/DESC）必须与每个OVER中完全一致 - WHERE 条件字段也应前置进键列（不是
INCLUDE），否则仍需过滤 - SELECT 中非键列用
INCLUDE，避免索引过大；已出现在键列里的字段不用重复INCLUDE
示例语句：
SELECT id, name, dept, region, salary,<br> ROW_NUMBER() OVER (PARTITION BY dept ORDER BY hire_date DESC) AS rn,<br> SUM(salary) OVER (PARTITION BY region ORDER BY created_at) AS cum_salary<br>FROM emp<br>WHERE status = 1 AND hire_date > '2020-01-01';
理想索引：
CREATE NONCLUSTERED INDEX idx_dept_region_sort ON emp (<br> status, hire_date DESC, created_at, dept, region<br>) INCLUDE (id, name, salary);
注意：status 放最左是因 WHERE 过滤；hire_date DESC 和 created_at 并列，是因为两个 ORDER BY 都要复用这个顺序；dept 和 region 在末尾，供分区跳转使用。
空OVER()和缺ORDER BY是隐形性能杀手
以下写法看似简洁，实则代价极高：
-
COUNT(*) OVER ()：强制全局排序，尤其在无聚集索引的堆表上，开销远超SELECT COUNT(*) FROM t -
ROW_NUMBER() OVER (PARTITION BY dept)：缺少ORDER BY，SQL Server 可能按物理存储顺序编号，结果不可控且无法利用索引 - 多个空括号
OVER()同时出现：每个都触发一次独立全表扫描
替代方案：
- 只取总数 → 先查
SELECT COUNT(*) FROM t WHERE ...，再 JOIN 回主查询 - 需要稳定排名 → 必须显式写
ORDER BY，且该列要有非空约束+对应索引 - 避免嵌套窗口，如
ROW_NUMBER() OVER (ORDER BY MAX(x) OVER (...))，这会让优化器彻底放弃排序复用
容易被忽略的兼容性与执行计划细节
不同版本 SQL Server 对窗口函数的优化能力差异很大：
- SQL Server 2016+ 才支持对
ROWS BETWEEN窗口框架做索引下推；2014 及更早版本遇到RANGE或未声明框架时，基本退化为排序+临时表 -
OPTION (RECOMPILE)对含参数的多窗口查询很关键——否则缓存的执行计划可能基于第一次的参数值，后续参数变化后严重失准 - 执行计划中若看到
Window Spool算子，说明窗口计算已物化到 tempdb，这是性能瓶颈信号，需检查是否可减少窗口数量或拆分查询
真正卡住的往往不是语法，而是你没意识到：同一个 OVER 子句里，PARTITION BY 字段顺序错了、ORDER BY 方向反了、或者 WHERE 条件字段没塞进索引键列——这些细节一错，前面所有优化都白搭。
