SQL Server分页实战：从ROW_NUMBER到OFFSET FETCH的优化指南

进入第80章。做开发这些年，分页查询算是我见过踩坑最多的 SQL Server 操作之一。表面上看，分页就是“取第 N 页的 M 条数据”，但真落到 SQL Server 上，你会发现它不像 MySQL 那样给个 LIMIT 就完事，还要面对语法版本差异、深分页性能、JOIN 去重、与 ORM 框架配合等一系列问题。这篇笔记把我自己多年做分页方案选型和实战排坑的经验完整梳理一遍，适合正在用 SQL Server 做业务系统开发、或者被分页性能问题困扰的读者。

这里说的“分页”，指的是后端数据库查询层面的分页，也就是根据页码和每页条数，从数据库里取固定范围的数据。很多刚接触 SQL Server 的朋友会困惑：为什么同样的需求，在 MySQL 里是 LIMIT 2, 10，在 SQL Server 里写法完全不一样？为什么网上搜到的分页写法有好几种，有的还只能在特定版本用？这些困惑的背后，其实是 SQL Server 分页方案在十几年间经历了三次比较大的演进。理清这条线，后面所有写法都不会乱。

1. 先把分页“为什么”想明白：SQL Server 分页的三层本质

1.1 分页要解决的三个核心问题

任何一个分页需求，拆到最底层都是三个问题：怎么定位到某一页的起始位置、怎么取固定条数、怎么告诉前端总共有多少条。听起来很简单，但实际处理时，每个问题都有隐藏的坑。

定位起始位置，是分页方案最核心的差异点。MySQL 的 LIMIT 10, 10 语义非常直白：跳过前面 10 条，取接下来 10 条。但 SQL Server 早期版本没有这种语法，只能靠“行号”间接实现，这就引出了 ROW_NUMBER() 这一大类方案。取固定条数相对简单，SQL Server 有 TOP 关键字，但 TOP 不能直接配合偏移量使用，所以又演化出了 OFFSET FETCH 这种“跳过 + 限定”的组合语法。至于总数，很多时候大家会在分页 SQL 里顺手加一个 COUNT(*) 子查询，但实际上 COUNT 的写法和性能影响点都不少，我在第 3 章会专门展开。

这三个问题里，定位和取数决定了分页 SQL 的骨架，总数决定了前端能不能正确渲染页码。业务系统里最常出现的“分页错乱”“重复数据”“越翻越慢”，基本都能追溯到这三个环节的某一步没处理好。

1.2 为什么 SQL Server 不像 MySQL 那样给个 LIMIT

我在给团队做技术分享时，几乎每次都会被问到：为什么 SQL Server 不直接支持 LIMIT？这跟 SQL Server 的历史包袱有关系。它的语法体系成型很早，TOP 关键字被各路存储过程用了十几年，贸然引入 LIMIT 会破坏大量存量代码的兼容性。所以在 2005 版本引入 ROW_NUMBER() 窗口函数，用“行号筛选”绕开了语法变更；到了 2012 版本才正式加入 OFFSET FETCH，这已经是相对现代的语法了。

这个演进过程直接影响了我们今天的选型：如果你维护的系统还跑在 SQL Server 2008 R2 甚至更老的版本上，OFFSET FETCH 是不支持的，只能老老实实用 ROW_NUMBER()。而如果数据库是 2012 以上版本，那 OFFSET FETCH 语法简洁、性能也更优，是首选。判断版本是第一步，很多“SQL 执行报错”的排查，最后都落在版本支持问题上。

2. 两种主流分页语法实操拆解

2.1 ROW_NUMBER() OVER()：一版通用方案

ROW_NUMBER() OVER() 分页的核心思路是：先按某个排序规则给每一行生成一个连续的行号，然后在外面包一层查询，用 WHERE 筛选出行号落在目标页码区间内的数据。

sql复制SELECT *
FROM (
    SELECT 
        ROW_NUMBER() OVER (ORDER BY OrderId) AS RowNum,
        OrderId,
        CustomerName,
        OrderAmount,
        OrderDate
    FROM dbo.Orders
) AS Paged
WHERE RowNum BETWEEN 11 AND 20
ORDER BY RowNum;

这段 SQL 的意思是取第 2 页数据，每页 10 条，BETWEEN 11 AND 20 对应的是“跳过前 10 条，取接下来的 10 条”。这里有几个细节必须注意。

第一，内层查询里的 ORDER BY 不能省略，否则 ROW_NUMBER() 计算出的行号没有确定性，分页结果会随机漂移。第二，外层查询的所有列，如果不是使用 * 通配，必须在内层子查询的 SELECT 列表里显式列出，否则外层引用不到。第三，分页条件尽量用 WHERE RowNum BETWEEN @Start AND @End，而不是 WHERE RowNum > @Start AND RowNum <= @End，虽然语义相同，但 BETWEEN 的边界更直观，便于维护。

这套方案的优点是兼容性极强，从 SQL Server 2005 一直到 2022 都能跑，老项目改造时基本不用动数据库版本。缺点是性能方面，它需要先对整个结果集排序并生成行号，再过滤。数据量小的时候感受不明显，但一旦到几十万上百万行，深分页（比如取第 10000 页）就会明显变慢，因为前 100000 行的排序和行号生成全部白算了一遍。

2.2 OFFSET FETCH：SQL Server 2012 之后的首选

OFFSET FETCH 是 SQL Server 2012 引入的分页语法，语义上比 ROW_NUMBER() 直观得多：先跳过多少行，再取多少行。

sql复制SELECT 
    OrderId,
    CustomerName,
    OrderAmount,
    OrderDate
FROM dbo.Orders
ORDER BY OrderId
OFFSET 10 ROWS
FETCH NEXT 10 ROWS ONLY;

OFFSET 10 ROWS 表示跳过 10 行，FETCH NEXT 10 ROWS ONLY 表示取接下来 10 行，合起来就是第 2 页的 10 条数据。这套写法的可读性比 ROW_NUMBER() 高了一个档次，而且不需要包一层子查询，SQL 引擎的优化器也能更直接地利用索引。

实际项目中，我们通常会把页号和页大小参数化，写成存储过程或者传给 ORM 的形式：

sql复制DECLARE @PageNumber INT = 2;
DECLARE @PageSize INT = 10;

SELECT 
    OrderId,
    CustomerName,
    OrderAmount,
    OrderDate
FROM dbo.Orders
ORDER BY OrderId
OFFSET (@PageNumber - 1) * @PageSize ROWS
FETCH NEXT @PageSize ROWS ONLY;

这里 OFFSET 后面的表达式可以包含变量和简单运算，SQL Server 是支持这种写法的。需要注意两点：OFFSET 子句不能单独省略，哪怕取第一页也要写 OFFSET 0 ROWS；FETCH NEXT 可以省略，但省略后就变成“跳过多少行之后一直取到末尾”，这在实际分页场景中没意义，所以通常两者都写全。

我个人的经验是：只要数据库版本允许，新开发的功能一律优先用 OFFSET FETCH。原因不只是语法简洁，更重要的是它在执行计划层面比 ROW_NUMBER() 更干净，尤其是在排序字段有索引支撑的时候，扫描范围更小。

2.3 两种方案实测对比与选型建议

为了让大家对性能差异有个直观感受，我拿一张 50 万行的订单表做过分页对比测试。表结构大概是：OrderId 是聚集索引主键，OrderDate 有非聚集索引，查询条件是按 OrderDate 排序后分页。

测试结果很有意思。取前几页的时候，ROW_NUMBER() 和 OFFSET FETCH 的耗时差距不大，都在几十毫秒以内。但取到第 20000 页的时候（OFFSET 199990 行），差距就拉开了。ROW_NUMBER() 方案耗时接近 8 秒，OFFSET FETCH 方案耗时约 3.2 秒。这个差距的根源在于，OFFSET FETCH 在执行计划里能被优化器识别为“排序后跳过 N 行”，有机会走索引有序扫描；而 ROW_NUMBER() 方案通常要先物化出带行号的完整结果集，再做过滤。

不过这个结论有一个重要前提：排序字段必须有索引支撑。如果排序字段没有索引，两种方案都会退化成全表排序，耗时相差不大，而且都是灾难性的慢。

选型建议分三种情况。第一，数据库版本在 2012 以下，没得选，用 ROW_NUMBER()。第二，数据库是 2012 及以上，且分页排序字段有索引配合，无脑选 OFFSET FETCH。第三，如果你做的是通用代码生成器、ORM 底层这类需要兼容多版本数据库的工具，可以考虑用 ROW_NUMBER() 做兜底方案，再根据版本动态切换到 OFFSET FETCH。我自己写公共分页组件时就是这么干的，版本识别逻辑也就几行代码。

3. 分页实战：高频复杂场景的完整解法

3.1 总数查询：COUNT 与 COUNT OVER 的选择

分页接口除了返回当前页数据，还必须返回总条数，否则前端没法渲染页码。这个总数查询看起来简单，实际上有两个常见问题：性能和一致性。

性能方面，COUNT(*) 在 50 万行的表上，如果只统计全表，走聚集索引扫描也要几十毫秒。如果分页查询本身还有 WHERE 过滤条件，那 COUNT 也得带着同样的 WHERE 条件再扫一遍，耗时翻倍。所以很多框架的默认做法是：分页数据查一次，COUNT 再查一次，总共两次查询。

一致性方面，如果两次查询之间数据发生了变化（比如有人插入了一条新订单），那分页数据的总数对不上，前端可能出现“最后一页没数据”或者“总页数变了”的体验问题。这个在多数业务系统里可以接受，但如果你做的是报表、对账这类对一致性敏感的场景，就得想想别的办法。

SQL Server 里有一个技巧可以用一条 SQL 同时拿到分页数据和总数：使用 COUNT(*) OVER()。下面这段 SQL 是我在项目里实际用过的写法：

sql复制SELECT 
    OrderId,
    CustomerName,
    OrderAmount,
    OrderDate,
    COUNT(*) OVER() AS TotalCount
FROM dbo.Orders
WHERE OrderDate >= '2025-01-01'
ORDER BY OrderId
OFFSET 0 ROWS
FETCH NEXT 10 ROWS ONLY;

每一行都会带一个 TotalCount 字段，值就是满足 WHERE 条件的总行数。这样做的好处是只需要一次查询，数据一致性也更好。但要注意几个坑：第一，如果当前页结果集为空，TotalCount 就不会返回，前端拿不到总数；第二，COUNT(*) OVER() 在数据量大时，会额外增加排序和统计的开销，所以更适合中等数据量（比如万级以下）的场景；第三，如果分页结果很大，每个行都重复带 TotalCount 会造成网络传输浪费，但这种场景本身就不该用这个方案。

我自己的习惯是：数据量 10 万以下，用 COUNT(*) OVER() 偷懒一次查询；数据量大或者复杂查询，老老实实分开查，而且 COUNT 语句的 WHERE 条件要跟分页查询完全一致，否则数据对不上。

3.2 JOIN 分页去重：先分页后关联

JOIN 分页是分页实战里最容易翻车的地方。打个比方：订单表 OrderHeader 和订单明细表 OrderDetail，一对多关系。如果你直接 JOIN 后再分页，一条订单有 3 条明细，那这一条订单会在结果集里出现 3 次，翻页时极大概率出现重复数据，而且总数也会变成明细条数而不是订单条数。

把问题“翻译”成分页三个核心问题就是：我们想分页的是“订单”，但 JOIN 之后被分页的是“订单 + 明细的组合行”。这完全是两种语义。

正确的解法是先分页主表，拿到主表主键，再去关联明细表。用 SQL Server 的写法，可以借助 CTE 或者子查询：

sql复制WITH PagedOrders AS (
    SELECT OrderId
    FROM dbo.OrderHeader
    ORDER BY OrderId
    OFFSET 0 ROWS
    FETCH NEXT 10 ROWS ONLY
)
SELECT 
    h.OrderId,
    h.CustomerName,
    d.ProductName,
    d.Quantity,
    d.Price
FROM PagedOrders p
INNER JOIN dbo.OrderHeader h ON p.OrderId = h.OrderId
LEFT JOIN dbo.OrderDetail d ON h.OrderId = d.OrderId
ORDER BY h.OrderId;

这段 SQL 的执行顺序是：先在 OrderHeader 上完成分页，只取 10 个 OrderId，然后再回到 OrderDetail 去取明细。这样就算一个订单有 50 条明细，它的主表记录也只会出现在一页里，不会跟其他订单混在一起。

需要注意，如果明细行数非常大，一页数据最终展开的行数可能远大于页大小。前端如果期望“一页就是 10 行”，那这种一对多展示就不适合用 JOIN 展开，而应该在应用层把明细聚合到一个字段里（比如用 FOR JSON、STRING_AGG 拼成 JSON），或者在前端做子表格展开。这也是实际项目里常见的取舍：数据库层只负责分页主表，明细交给应用层二次查询。

3.3 动态排序与参数化：白名单动态 SQL

分页查询跟排序是强绑定的，因为无论是 ROW_NUMBER() 还是 OFFSET FETCH，都强制要求有 ORDER BY。但业务系统里，排序字段经常是用户在前端点表头动态指定的，比如“按金额升序”“按日期降序”。这时候如果你天真地写：

sql复制ORDER BY @SortColumn

在 SQL Server 里，这个 ORDER BY 变量是不会按你期望的列排序的，它会被当作常量处理，本质上等于没排序。这是一个非常隐蔽的问题，我见过不止一个同事在这里踩坑。

正确的解法有两种。第一种是全动态 SQL 拼接，把列名拼进去，但必须做白名单校验，防止 SQL 注入。第二种是 CASE WHEN 表达式：

sql复制ORDER BY 
    CASE WHEN @SortColumn = 'OrderAmount' THEN OrderAmount END ASC,
    CASE WHEN @SortColumn = 'OrderDate' THEN OrderDate END DESC;

CASE WHEN 方式避免了动态 SQL，但存在两个问题：多个 CASE 条件叠加时，SQL 引擎很难有效利用索引，排序性能会差；如果同时要支持多个排序列的混合升降序，CASE WHEN 的写法会迅速变得混乱难维护。所以我的建议是：能用白名单动态 SQL 就用动态 SQL，前提是严格校验列名。

sql复制DECLARE @SortColumn SYSNAME = N'OrderAmount';
DECLARE @SortDirection VARCHAR(4) = N'DESC';

IF @SortColumn NOT IN (N'OrderId', N'OrderAmount', N'OrderDate')  
    SET @SortColumn = N'OrderId';
IF @SortDirection NOT IN (N'ASC', N'DESC')  
    SET @SortDirection = N'DESC';

DECLARE @Sql NVARCHAR(MAX) = N'
SELECT 
    OrderId,
    CustomerName,
    OrderAmount,
    OrderDate
FROM dbo.Orders
ORDER BY ' + QUOTENAME(@SortColumn) + N' ' + @SortDirection + N'
OFFSET 0 ROWS
FETCH NEXT 10 ROWS ONLY;';

EXEC sp_executesql @Sql;

这里用 QUOTENAME 包了一下列名，再加一层 NOT IN 白名单校验，双保险。动态 SQL 不是洪水猛兽，只要校验严格、参数化到位，很多复杂场景靠它比靠 CASE WHEN 性能好得多。

3.4 深分页性能杀手与 Keyset 游标分页

如果你维护的系统数据量已经到百万级，而且用户真的会翻到几百上千页，那不管用 ROW_NUMBER() 还是 OFFSET FETCH，都会明显变慢。原因很简单：OFFSET 是“跳过 N 行”，数据库必须先把前面 N 行都读出来、扔掉，再返回目标行。这种深分页的计算量是线性增长的，越翻越慢。

有一种业界常用的优化思路叫 Keyset 分页，也叫游标分页或者 Seek 分页。它的核心思想是：不按页码跳，而是记住上一页最后一条数据的排序键值，下一页从那个键值之后继续取。SQL Server 里用 TOP 就能实现：

sql复制-- 第一页：没有上一页游标，直接取前 10 条
SELECT TOP (10)
    OrderId,
    CustomerName,
    OrderAmount,
    OrderDate
FROM dbo.Orders
WHERE OrderDate > @FirstPageLastOrderDate  -- 上一页最后一条的 OrderDate
ORDER BY OrderDate, OrderId;

这里的通过 WHERE 条件把扫描起点直接定位到上一页结尾之后，数据库可以直接走索引查找，而不是从头扫描。性能消耗基本恒定，不管翻到第 100 页还是第 10000 页，耗时几乎一样。

但 Keyset 分页有两个明显的限制。第一，不支持直接跳页，只能上一页、下一页地翻。第二，如果排序字段有重复值，必须追加唯一键（比如主键 OrderId）作为第二排序条件，否则可能会出现重复或丢失数据。例如：如果按 OrderDate 排序且同一天有大量订单，那 WHERE OrderDate > @Last 就会把同时间戳的数据跳到下一页，上一页的最后几条和下一页的前几条会出现空洞或重复。解决办法就是加一个 OrderId 作为 tiebreaker。

Keyset 分页适合什么场景？移动端瀑布流、IM 聊天记录、日志浏览、新闻信息流，这些场景用户一般不会精确跳到第 57 页，而是不停地“加载更多”。反过来，传统管理后台的表格翻页，用户习惯直接点页码，那还是老老实实用 OFFSET FETCH 配合索引优化，必要时限制最大页码或者用缓存兜底。

4. 分页与周边生态联动：ORM、前端与缓存

4.1 ORM 框架如何生成分页 SQL

大多数日常开发不会直接手写分页 SQL，而是通过 ORM 框架。理解框架底层生成的分页语句，对排查问题至关重要。

EF Core 里写分页就是 LINQ 的 Skip().Take()：

csharp复制var page = dbContext.Orders
    .OrderBy(o => o.OrderId)
    .Skip(20)
    .Take(10)
    .ToList();

EF Core 针对 SQL Server 提供程序会把这段 LINQ 翻译成 OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY（前提是数据库版本 2012+）。如果你用的是老版本映射，或者某些特殊查询被翻译成了客户端评估，生成的可能就是 ROW_NUMBER() 子查询。所以排查 EF Core 分页慢时，第一步是把生成的 SQL 打出来看，确认走的是哪套方案。

MyBatis 的场景更复杂一些。MyBatis 本身没有内置分页能力，大部分项目依赖 PageHelper 这种分页插件。PageHelper 的原理是拦截你的查询 SQL，自动包一层 COUNT 查询，再改写原 SQL 追加分页语句。在 SQL Server 方言下，它会根据配置生成 OFFSET FETCH 或 ROW_NUMBER() 分页。

PageHelper 有一个让我印象深刻的坑：ThreadLocal 污染。分页参数是存在当前线程的 ThreadLocal 里的，如果你在查询之后忘记调用 PageHelper.clearPage()，下一个查询可能会被莫名分页，导致“查询结果被截断”这种诡异问题。网上搜“若依 分页查询”能搜到大量类似问题，很多都是这个原因。

4.2 与前端分页组件的数据契约

分页 SQL 写好了，还得跟前端对上话。现在主流前端组件库的分页组件（比如 Element UI 的 el-pagination）对后端的数据契约要求基本一致：当前页 current、每页条数 pageSize、总条数 total、列表数据 list。后端返回的 JSON 结构通常长这样：

json复制{
  "code": 200,
  "msg": "success",
  "total": 1024,
  "rows": [
    { "OrderId": 11, "CustomerName": "张三" }
  ]
}

这正好对应若依这种后台管理框架的统一返回结构。后端从 SQL 拿到分页数据和总数后，组装成这个结构返回即可。前端的核心公式也很简单：请求第 N 页时，传 (current - 1) * pageSize 给后端作为 OFFSET 值，或者直接传 current 和 pageSize 让后端自己算。

这里有个容易忽视的点：前端页码的起始值。绝大多数前端分页组件的页码从 1 开始，但有些后端框架或接口设计习惯从 0 开始。如果前后端对不上，就会出现第一页有数据的错觉，实际上数据整体错位。我在联调时遇到过几次，排查到最后都是页码起始值约定不一致，所以建议在接口文档里明确写上“页码从 1 开始”。

4.3 Redis 加速分页查询的实践方案

搜“分页查询慢怎么用 redis 优化”的人很多，但我先说结论：Redis 不是分页的万能解药，用不好反而会引入数据一致性问题。合理的应用场景是读多写少、数据量大、实时性要求不高的列表页。

最稳的 Redis 分页方案不是缓存分页结果，而是缓存“排序后的主键列表”。举个例子，获取 50 万个订单 ID 并按时间排序后写入一个 Redis ZSET，score 就是订单时间截，member 就是 OrderId。前端请求第 N 页时，用 ZRANGE 从 ZSET 里取一页的 OrderId，然后再拿这些 ID 回 SQL Server 批量查询完整数据。

bash复制# 写入缓存时，伪代码示意
ZADD order_index 1750000000 1001
ZADD order_index 1750000001 1002

# 取第 2 页 10 条
ZRANGE order_index 10 19

# 拿 ID 列表回表查询
SELECT * FROM Orders WHERE OrderId IN (1010, 1011, ...)

这样分页的大开销（排序、跳过）被转移到了 Redis 的内存数据结构上，速度是毫秒级的。但同时要处理两个问题：一是 ZSET 里的索引数据怎么保证不过期、不脏，通常配合定时重建或者延迟更新；二是回表查询时要注意 IN 的 ID 数量不能太大，否则一条 SQL 塞几万个 ID 会引发参数过多或执行计划问题。

我还见过另一种方案：用 Redis List 直接存分页结果，但这种方式我只建议在数据基本不变的场景用，比如配置表、字典表。业务数据一变，缓存里各页的数据就全乱了，清理和重建成本极高。说到底，Redis 优化分页的本质是“用内存换查询深度”，不是“缓存了事”。

5. 分页高频问题与排查技巧速查

5.1 常见报错与解决办法

分页报错类型比较集中，下面这个表是我整理的高频问题速查，基本覆盖了日常开发的绝大多数场景。

5.2 分页性能排查三板斧

第一板斧：看执行计划和索引。分页 SQL 慢，百分之八十是因为排序字段没有索引，或者 WHERE 过滤字段没有索引。打开“显示估计的执行计划”，如果看到 Table Scan 或者 Sort 算子的代价占比特别高，优先补索引。对于 OFFSET FETCH 分页，理想的索引是排序字段和 WHERE 字段组成的复合索引。

第二板斧：看逻辑读。使用 SET STATISTICS IO ON 查看分页查询的逻辑读次数。如果取第 10 页的逻辑读和取第 10000 页的逻辑读线性增长，说明深分页问题已经存在，考虑 Keyset 分页或者限制可翻页深度。如果逻辑读很高但页面返回很少，有可能是索引缺失导致的 RID Lookup 或者 Key Lookup。

第三板斧：监控缓冲池和内存。网上搜“分页缓冲池占用很高”能搜到很多求助帖，这里要说明白：它指的不是分页查询，而是 SQL Server 的 Buffer Pool 占用过高，通常是内存压力大、max server memory 设置不合理、或者大量全表扫描把不常用数据页冲进缓存导致的。问题根源往往是查询缺索引，而不是分页本身。排查时用 sys.dm_os_buffer_descriptors 看看哪些表占用了大量缓冲池页，重点优化那些对象的访问路径。我之前处理过一个线上案例，一个 200GB 的大表没有合适索引，每次分页查询都全表扫描，把 Buffer Pool 刷得惨不忍睹，其他正常查询全部变慢。加了复合索引之后，缓冲池压力立刻降下来，分页查询本身也从 10 秒级降到几百毫秒。

这个案例给我一个很深的体会：分页慢从来不是“分页语法”的问题，而是它背后的排序、扫描、内存这三件事出了问题。语法只是表，索引和内存策略才是里子。

从 ROW_NUMBER() 到 OFFSET FETCH，再到 Keyset 分页，这条路我踩了无数坑才彻底走通。最后再分享一个小习惯：不管用哪种分页方案，我都会在代码注释里标明最低数据库版本要求和排序字段的索引要求。这个习惯让我在半年后回来看代码时，不用重新推理一遍就能快速定位问题。分页这块的知识点细碎，但只要你把“定位起始位置、取固定条数、获取总数”这三件事拆清楚，再按版本和数据量选型，基本就不会翻车了。