SQL Server窗口函数ROW_NUMBER分页如何优化-SQL-PHP中文网

row_number() 分页慢主因是排序未走索引，需为over子句字段建匹配联合索引，过滤条件须下推至内层子查询，超万级偏移量应改用游标分页。

sql server窗口函数row_number分页如何优化

ROW_NUMBER() 分页慢，八成是没走索引

SQL Server 执行 ROW_NUMBER() 时，必须先完成排序才能编号。如果 OVER (ORDER BY ...) 里的字段没对应索引，引擎会强制走 Sort 算子——百万行就可能吃光内存、撑爆 tempdb，执行计划里一眼就能看到红色警告图标。

关键不是“用了窗口函数”，而是“排序能不能被索引覆盖”。比如写 ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC)，就必须建联合索引：CREATE INDEX IX_orders_time_id ON Orders(created_at DESC, id DESC)；若查询还常带 WHERE status = 'shipped'，索引得改成：CREATE INDEX IX_orders_status_time_id ON Orders(status, created_at DESC, id DESC)。

单列索引对多列 ORDER BY 基本无效，别指望它能用上
ORDER BY 里别用表达式，像 ORDER BY DATEADD(day, 1, created_at) 直接让索引失效
聚集索引列天然有序，但若 OVER 排序顺序和聚集键不一致（比如聚集索引是 id ASC，却按 created_at DESC 排），照样要额外排序

WHERE 条件写错位置，性能直接归零

很多人把过滤条件全堆在外层 WHERE，比如在 ROW_NUMBER() 子查询外加 AND status = 'paid'。这会导致 SQL Server 先给全部 500 万行编号，再过滤——编号过程本身已耗尽资源，过滤只是收尾动作。

正确做法是：所有业务过滤条件（WHERE）必须下推到最内层子查询中，确保参与编号的行数尽可能少。

错误写法：SELECT * FROM (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM Orders) t WHERE t.status = 'paid' AND t.rn BETWEEN 101 AND 120
正确写法：SELECT * FROM (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM Orders WHERE status = 'paid') t WHERE t.rn BETWEEN 101 AND 120
别省略子查询别名（如 t），否则 t.rn 报错 Invalid column name 'rn'

rn BETWEEN 写法比 > /

看起来只是语法差异，但 rn BETWEEN @start AND @end 能让优化器识别出这是 TopN 场景，有机会生成 Top N Sort 算子；而 rn > @start AND rn 会被当作普通过滤，无法触发该优化，执行计划里会多出 <code>Compute Scalar 和全量 Filter。