SQL Server分页查询怎么写？三种高效分页方案详解

在大数据量场景下，分页查询是SQL Server中最常见也是最容易出现性能瓶颈的操作之一。传统分页写法在数据量增长后往往会变慢甚至“卡死”。本文将系统讲解SQL Server分页实现方式及高性能优化方案，帮助你构建可扩展的分页系统。

SQL Server常见分页方式

1. OFFSET + FETCH（推荐基础方案）

适用于 SQL Server 2012+：

SELECT *
FROM Users
ORDER BY Id
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

• OFFSET：跳过前 N 条记录
• FETCH NEXT：获取指定数量记录

优点是语法简单、易读，是目前主流分页方式。但它有一个致命问题：当页数越大时，性能会急剧下降。原因是数据库必须扫描并跳过前面的数据。

2. ROW_NUMBER() 分页（经典方案）

SELECT *
FROM (
    SELECT ROW_NUMBER() OVER (ORDER BY Id) AS RowNum, *
    FROM Users
) AS T
WHERE RowNum BETWEEN 21 AND 30;

优点：兼容旧版本 SQL Server，灵活性高

缺点：必须对全表排序并生成行号，数据量大时性能较差

3. Keyset（游标）分页（高性能推荐）

SELECT TOP 10 *
FROM Users
WHERE Id > @LastId
ORDER BY Id ASC;

核心思想：

• 不使用 OFFSET
• 使用上一页最后一条记录作为游标

优点：性能稳定，适合百万级数据，避免扫描无效数据

分页性能瓶颈分析

1. 大 OFFSET 问题

OFFSET 100000 ROWS FETCH NEXT 10 ROWS

数据库需要扫描 100000 行，然后丢弃这些数据，只返回 10 行，这会导致 CPU 和 IO 浪费严重。

2. 排序字段无索引

分页依赖 ORDER BY，如果没有索引，会触发全表扫描，甚至使用临时表排序。

3. SELECT *

返回不必要字段，会增加 IO，降低缓存命中率。

高效分页设计核心原则

1. 必须建立合适索引（最关键）

CREATE INDEX idx_users_created_id
ON Users (CreatedAt DESC, Id DESC);

说明：

• 排序字段必须有索引
• 推荐联合索引（避免回表）

索引能显著减少磁盘IO，提高查询效率。

2. 使用覆盖索引（减少回表）

CREATE INDEX idx_users_cover
ON Users (CreatedAt)
INCLUDE (Name, Email);

好处：

• 查询直接从索引获取数据
• 避免访问主表

3. 大数据分页优先使用 Keyset

适用场景：

• 无限滚动（Feed流）
• 评论列表
• 日志系统

优势：

• 性能不随页数增长
• 可实现秒级响应

4. 避免深分页（Deep Pagination）

不推荐：OFFSET 1000000 ROWS

优化方案：

• 限制最大页数
• 使用游标分页替代
• 或改为加载更多

5. 分页 + 主键二次查询（高阶优化）

-- 第一步：只查ID
SELECT Id
FROM Users
ORDER BY Id
OFFSET 100000 ROWS FETCH NEXT 10 ROWS;

-- 第二步：回表查询
SELECT *
FROM Users
WHERE Id IN (...)

优势：

• 减少扫描字段
• 提升性能

分页方案对比总结

最佳实践建议（实战总结）

如果你要设计一个高性能分页系统，建议：

• 小数据量：直接用 OFFSET
• 中数据量：OFFSET + 索引优化
• 大数据量：Keyset分页 + 覆盖索引
• 高并发场景：限制最大页数，使用缓存（Redis），避免 COUNT(*)

总结

SQL Server分页性能的核心问题并不在语法，而在数据扫描方式。

• OFFSET 本质是跳过数据
• ROW_NUMBER 本质是全量排序
• Keyset 才是精准定位

真正高效的分页 = 索引 + 合理分页策略 + 避免深分页。