窗口函数本身不慢，慢因是未为PARTITION BY和ORDER BY字段建索引或误在WHERE中使用；ORDER BY无索引会触发多次排序，导致性能下降。
窗口函数本身不慢，慢的是没配好 PARTITION BY 和 ORDER BY 字段的索引，或误用在 WHERE 条件里。
为什么加了 OVER 还是慢？关键看排序开销
窗口函数执行时，ORDER BY 是唯一可能触发强制排序的环节。如果 ORDER BY hire_date 字段没有索引，SQL Server 就得为每个 PARTITION BY dept_id 单独做一次内存或磁盘排序——数据量一大，Sort 运算符就会出现在执行计划顶部，且 ActualRows 常远超表总行数。
- 检查执行计划：找
Sort或Top N Sort物理运算符，右键看“Estimated I/O Cost”是否显著偏高 - 优先给
ORDER BY字段建索引，例如CREATE INDEX IX_orders_user_id_order_date ON orders(user_id, order_date)，这样SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date)就能流式计算 - 若业务允许近似结果，可考虑去掉
ORDER BY（如仅需分组内总和），此时窗口函数退化为无序聚合，几乎零排序开销
别在 WHERE 里直接用窗口函数结果
像 WHERE ROW_NUMBER() OVER (ORDER BY score DESC) 这种写法会报错：<code>Windowed functions can only appear in the SELECT or ORDER BY clauses。窗口函数不能参与过滤逻辑，因为其值依赖于整个结果集已生成。
- 正确做法是套一层 CTE 或子查询：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY score DESC) rn FROM students) t WHERE t.rn - 注意：CTE 不是视图，SQL Server 2016+ 默认不物化它；若该 CTE 被多次引用，建议显式用
SELECT ... INTO #temp落临时表，避免重复计算 - 若只需 Top N 且不关心排名稳定性，
TOP 10 ... ORDER BY score DESC更轻量，无需窗口函数
哪些场景必须用窗口函数，哪些其实可以不用？
窗口函数真正不可替代的，是“单行输出 + 整组上下文”的需求。一旦出现“每行都要查一遍其他行”，基本就是窗口函数的主场；反之，纯单值判断或静态聚合，关联子查询或 JOIN 可能更直观。
- 该用窗口函数的：累计求和（
SUM(sales) OVER (ORDER BY date ROWS UNBOUNDED PRECEDING)）、移动平均、前后行对比（LAG(price) OVER (PARTITION BY product_id ORDER BY ts)）、分组内去重编号（DENSE_RANK() OVER (PARTITION BY category ORDER BY price)） - 不该硬套窗口函数的：只查“用户最新一条订单”，用
OUTER APPLY (SELECT TOP 1 ... ORDER BY created_at DESC)更清晰；只取“部门平均薪资”，直接AVG(salary) OVER (PARTITION BY dept_id)没问题，但若后续还要WHERE avg_salary > 10000，就得改用 GROUP BY + HAVING - 特别注意
RANGE和ROWS的语义差异：RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW对重复ORDER BY值会合并计算，而ROWS严格按物理行位置——业务逻辑要求精确到行序时，必须用ROWS
最容易被忽略的是：窗口函数的 PARTITION BY 字段即使有索引，也不能跳过排序；索引只能加速 ORDER BY 阶段的数据定位，不能省掉排序动作本身。所以性能瓶颈永远落在 ORDER BY 字段是否有序、是否覆盖、是否需要去重这三个点上。
