ROW_NUMBER分页变慢的根本原因是执行计划出现“全表扫描+全量排序+后过滤”，而非函数本身；应确保排序字段有覆盖索引、过滤条件下推至内层子查询，并满足Top N Sort触发条件以提升性能。
为什么ROW_NUMBER分页执行计划会变慢
根本原因不是ROW_NUMBER()本身，而是执行计划里出现了“全表扫描 + 全量排序 + 后过滤”三连击。比如你只想要第10001–10020行，但SQL Server先对千万级关联结果排完序、编完号，再用WHERE rn BETWEEN 10001 AND 10020去筛——编号过程已消耗全部资源。
常见错误现象包括：Estimated Number of Rows在ROW_NUMBER节点显示几百万，Sort操作占执行时间70%以上，Top N Sort没出现反而看到Compute Scalar + Filter组合。
- 排序字段没索引：强制走
Sort，无法利用索引有序性 -
WHERE条件写在外层：内层子查询没过滤，编号基数过大 -
ORDER BY含非索引列（如u.name）或NULL值未处理：优化器放弃索引查找 - 视图封装过深：在视图上直接套
ROW_NUMBER()，导致底层JOIN无法下推谓词
如何让执行计划出现Top N Sort
Top N Sort是健康信号，说明SQL Server识别出“只需前N行有序”，能提前终止排序。触发它需要同时满足：
- 最内层查询的
ORDER BY字段必须有覆盖索引，且顺序与ROW_NUMBER() OVER (...)完全一致 - 所有业务过滤条件（如
status = 'paid'）必须写在ROW_NUMBER()所在子查询内部 - 避免在
OVER子句里用表达式排序，例如ORDER BY YEAR(create_time)——索引失效 - 若排序字段可能为NULL，用
CASE WHEN create_time IS NULL THEN 1 ELSE 0 END, create_time DESC代替裸列，避免隐式转换干扰索引选择
示例索引建议：CREATE INDEX IX_orders_status_created_id ON orders(status, created_at DESC, id DESC)，这样WHERE status = 'paid' ORDER BY created_at DESC, id DESC可全程走索引查找+流式排序。
三层嵌套结构怎么写才不崩执行计划
不是为了“看起来规范”而套三层，是让优化器有足够信息做谓词下推。标准结构必须是：
SELECT id, title, created_at
FROM (
SELECT id, title, created_at,
ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn
FROM posts
WHERE status = 'published' -- ✅ 过滤必须在这里
) t
WHERE t.rn BETWEEN 101 AND 120;关键点：
- 最内层只做数据获取+过滤，不选无关字段（避免宽表IO放大）
- 中间层只加
ROW_NUMBER()，不加JOIN或GROUP BY——这些会破坏排序流式化 - 外层只做
rn范围过滤，别加AND status = 'published'——重复条件会导致优化器误判基数 - 如果涉及多表JOIN，把JOIN和WHERE全写在最内层，不要在CTE里只
SELECT *再JOIN
动态拼接时怎么保住执行计划复用
用sp_executesql时，只要参数化到位，执行计划就能缓存复用。但以下操作会直接让计划失效：
- 拼接表名/字段名时没用
QUOTENAME()：遇到table_name = 'orders; DROP TABLE users--'就炸了，且不同表名生成不同计划 - 把用户输入的值（如日期字符串）拼进SQL：例如
@sql = '... WHERE create_time > ''' + @date + ''''→ 每次都新编译 - WHERE条件片段拼接时没校验单引号：传入
O'Reilly直接语法错误
正确做法：
DECLARE @sql NVARCHAR(MAX) = N' SELECT id, title FROM ( SELECT id, title, ROW_NUMBER() OVER (ORDER BY ' + QUOTENAME(@sort_col) + N' DESC) AS rn FROM ' + QUOTENAME(@table_name) + N' WHERE status = @status_param ) t WHERE t.rn BETWEEN @start AND @end'; <p>EXEC sp_executesql @sql, N'@status_param VARCHAR(20), @start INT, @end INT', @status_param = 'published', @start = 101, @end = 120;
注意：@sort_col和@table_name可拼接（需QUOTENAME），但所有值类参数必须走@param占位符——这是执行计划能否复用的分水岭。
复杂点在于，一旦排序字段或过滤逻辑随业务变化，就必须重新评估索引是否覆盖；容易被忽略的是，ROW_NUMBER()的ORDER BY哪怕只差一个DESC，也可能让已有索引彻底失效。
