offset fetch 在大表关联视图上极慢，因其需扫描跳过前n行；而 row_number() 提前编号再过滤可避免全量排序与关联，配合索引能显著提升性能。
为什么直接用 OFFSET FETCH 在大表关联视图上会慢得离谱
因为 SQL Server（或 PostgreSQL）执行 OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY 时，仍需扫描并跳过前 10000 行——哪怕你只想要第 10001–10020 行。当视图底层是多张大表 JOIN（比如千万级订单 + 百万级用户 + 十万级商品），每次分页都触发全关联+全排序+全跳过，IO 和 CPU 压力陡增。
常见错误现象：SELECT * FROM my_view ORDER BY id OFFSET 50000 ROWS FETCH NEXT 10 ROWS ONLY 执行超 8 秒，且执行计划里出现大量“Sort”和“Nested Loops”回表。
- 关联字段没索引？必然慢
- 视图里用了
SELECT *或未明确ORDER BY？优化器无法复用排序结果 - 没把分页逻辑下推到最内层？外层视图再套分页等于雪上加霜
用 ROW_NUMBER() 替代 OFFSET FETCH 的正确写法
核心思路：把分页计算提前到 JOIN 完成后、但尚未返回所有字段前，用 ROW_NUMBER() 标记序号，再用外层 WHERE 筛选范围。这样避免重复计算，也便于索引利用。
SELECT id, user_name, order_amount
FROM (
SELECT
o.id,
u.user_name,
o.order_amount,
ROW_NUMBER() OVER (ORDER BY o.id) AS rn
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'paid' -- 尽量把过滤条件放这里
) t
WHERE t.rn BETWEEN 10001 AND 10020;
关键点：
-
ROW_NUMBER()的ORDER BY必须和最终分页排序一致，否则序号无意义 - 过滤条件（如
WHERE o.status = 'paid'）尽量写在子查询内，减少参与编号的行数 - 不要对视图本身套
ROW_NUMBER()，而要在视图展开后的基础表上做——否则可能绕过索引
性能差异在哪？看执行计划里的三个关键信号
对比两种写法，重点关注：
- 是否出现“Top N Sort”（好） vs “Sort + Compute Scalar + Filter”（坏）
- “Estimated Number of Rows” 在
ROW_NUMBER()节点是否接近你期望的页大小（比如 20），而不是百万级 - JOIN 是否发生在
ROW_NUMBER()之前，且关联字段有覆盖索引（例如orders(user_id, status, id)）
容易踩的坑：
- 在
ROW_NUMBER()的OVER子句里用了非索引字段排序（如ORDER BY u.name），导致强制排序 - 把
rn BETWEEN写成rn > 10000 AND rn —— SQL Server 对前者优化更好 - 忘了给排序字段建索引：没有
INDEX ON orders(id)，ROW_NUMBER() OVER (ORDER BY o.id)依然很慢
带参数的存储过程怎么安全传入页码和页大小
别拼接字符串，用参数化防止注入，同时避免参数嗅探导致计划劣化：
CREATE PROCEDURE GetOrdersPage @PageNumber INT = 1, @PageSize INT = 20 AS BEGIN DECLARE @StartRow INT = (@PageNumber - 1) * @PageSize + 1; DECLARE @EndRow INT = @PageNumber * @PageSize; <p>SELECT id, user_name, order_amount FROM ( SELECT o.id, u.user_name, o.order_amount, ROW_NUMBER() OVER (ORDER BY o.id) AS rn FROM orders o WITH (NOLOCK) JOIN users u WITH (NOLOCK) ON o.user_id = u.id WHERE o.status = 'paid' ) t WHERE t.rn BETWEEN @StartRow AND @EndRow; END</p>
注意：
-
WITH (NOLOCK)要按业务容忍度决定是否加，不是万能提速项 - 参数类型必须和计算一致：
@PageNumber用INT，别用VARCHAR再转 - 如果页码极大（如 > 100000），
ROW_NUMBER()仍需生成全部序号，此时应改用键集分页（Keyset Pagination），用上一页最后的id作为下一页起点
分页不是加个 ROW_NUMBER() 就万事大吉；真正卡点往往在索引设计是否匹配排序+过滤组合，以及你有没有把计算压到数据最少的那一层。
