根本原因是索引字段顺序未匹配OVER子句的PARTITION BY和ORDER BY顺序：必须按分区字段（最左）、排序字段（次左）、WHERE条件字段（再后）构建复合索引，且方向一致；空ORDER BY会触发隐式全表排序，导致性能骤降。
为什么加了索引，OVER子句还是慢
根本原因不是索引没建，而是索引没“对上”OVER里用的字段顺序和筛选条件。SQL Server 在执行 ROW_NUMBER() OVER (PARTITION BY a ORDER BY b) 时，需要先按 a 分区、再在每个分区内按 b 排序——如果索引是 (b, a)，它无法跳过排序步骤；必须是 (a, b) 才能直接复用索引顺序。
常见错误现象：SELECT * FROM t WHERE status = 10 ORDER BY created_at 很快，但套上 ROW_NUMBER() OVER (ORDER BY created_at) 就变慢，就是因为没把 status 和 created_at 同时纳入索引键。
- 分区字段（
PARTITION BY）必须放在索引最左侧 - 排序字段（
ORDER BY）紧随其后，且方向一致（ASC/DESC要匹配） - 查询中用到的
WHERE条件字段，也应前置进索引，否则仍需回表或过滤
覆盖索引怎么写才真正“覆盖”OVER子句
所谓“覆盖”，是指索引里包含 OVER 计算所需的所有字段 + 查询 SELECT 列，让 SQL Server 不用访问堆或聚集索引就能完成全部操作。
比如这个语句：
SELECT id, name, dept, salary, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn FROM emp WHERE status = 1;
理想索引应为：
CREATE NONCLUSTERED INDEX idx_dept_salary_cover ON emp (dept, salary DESC, status) INCLUDE (id, name, salary);
-
dept和salary DESC对齐PARTITION BY+ORDER BY -
status放在键列里（不是INCLUDE），才能高效过滤WHERE status = 1 -
INCLUDE只放SELECT中非键列（id,name），避免索引过大；salary已在键列中，INCLUDE里可不重复加
ORDER BY 缺失或空 OVER() 是性能隐形杀手
ROW_NUMBER() OVER (PARTITION BY dept) 看似合法，但 SQL Server 实际会按任意物理顺序编号——每次执行结果可能不同，且优化器往往退化为全表扫描+临时排序。更糟的是，COUNT(*) OVER () 这种空括号写法，在 SQL Server 中虽不报错，但会强制触发全局排序，尤其当表无聚集索引时，开销极大。
- 所有排名函数（
ROW_NUMBER、RANK、DENSE_RANK）必须带ORDER BY，否则行为不可控 - 聚合窗口函数（如
SUM(salary) OVER (PARTITION BY dept)）可不写ORDER BY，但若后续要取“每个部门薪资累计值”，就必须加，否则默认窗口是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，而该框架依赖排序 - 想避免隐式排序？优先用
OFFSET-FETCH分页替代ROW_NUMBER()套子查询，尤其在 SQL Server 2012+ 环境下
多个窗口函数共存时，索引还能复用吗
可以，但前提是它们的 PARTITION BY 和 ORDER BY 完全一致。例如：
SELECT ROW_NUMBER() OVER (PARTITION BY dept ORDER BY hiredate) AS rn, AVG(salary) OVER (PARTITION BY dept ORDER BY hiredate) AS avg_so_far, FIRST_VALUE(name) OVER (PARTITION BY dept ORDER BY hiredate) AS first_hire FROM emp;
这种写法只用一次排序，索引 (dept, hiredate) 就够用。但如果混用不同分区或排序，比如再加一个 LAG(salary) OVER (ORDER BY id)，SQL Server 就得额外做一次全表排序——执行计划里会出现两个 Sort 操作符。
- 检查执行计划：找
Sort节点数量，一个以上就说明窗口函数没共享排序 - 优先合并逻辑：把同分区同排序的窗口函数写在一起，避免拆成多个 CTE 或子查询
- 不要为了“看起来清晰”而强行拆分窗口计算，实际代价可能翻倍
真正卡住性能的，往往不是语法写错，而是索引没对准窗口的分区+排序组合，或者低估了空 ORDER BY 引发的隐式排序成本。动手建索引前，先看执行计划里的 Sort 和 Index Scan/Seek 比例——比盲加索引管用得多。
