在实际开发中，分页查询频繁使用，但随着数据量增长，如果方法选取不当，会显著拖慢性能。本文聚焦 SQL Server 分页查询最佳实践，帮助你在大数据场景下提升响应速度与系统可扩展性。
1. 使用 OFFSET…FETCH 分页（适用于 SQL Server 2012 及以上）
推荐在 ORDER BY 子句中使用 OFFSET X ROWS FETCH NEXT Y ROWS ONLY 来完成分页。这种方式简单易读，并由引擎原生支持分页逻辑，适合小到中等偏移量的场景。
不过，当页码偏移较大时（如跳转至第数万页），OFFSET 会扫描并跳过大量行，带来显著性能下降。
2. 基于键或主键的分页（Keyset Pagination / Seek 方法）
对于大偏移量或深度分页场景，基于键的分页更有效。比如根据主键 ID 或时间戳记住上一页最后一条记录的值，下次查询时用 WHERE id > last_id ORDER BY id OFFSET 0 ROWS FETCH NEXT N ROWS，避免全表扫描，实现常数时间翻页。
也可使用子查询或延迟关联（INNER JOIN）形式，以减少数据扫描和避免临时表性能开销。
3. 深度分页的优化技巧
当用户需要跳转近尾页或偏移量极大时，结构性优化尤为关键：
范围查询 / 标签记录法：记录上一页的终点 ID，下一页使用 WHERE id < lastId 或者 id BETWEEN minId AND maxId 来限制范围查询，减少扫描量。
子查询 + JOIN 延迟关联：先查询目标区域的主键值，再通过 INNER JOIN 将完整记录关联出来，性能优于直接大 OFFSET 查询。
覆盖索引：如果分页查询仅涉及少量字段，可以为 ORDER BY 和 SELECT 中的字段创建覆盖索引，避免回表操作，显著提升 I/O 性能。
4. 索引设计与执行计划优化
分页相关的 ORDER BY 字段（如主键、时间戳）应建立合适索引，并尽量避免在 WHERE 或 ORDER 子句中使用函数或类型转换，防止索引失效。
覆盖索引（covering index）也能避免额外回表，极大优化访问效率。
使用执行计划分析工具（如 SSMS 执行计划查看器）识别 Table Scan、Sort 操作等瓶颈，必要时重新设计索引结构。
5. 自定义分页、自定义逻辑和缓存设计
在 ASP.NET 等 Web 场景中，如果内建分页逻辑会将整表载入内存，不推荐用于大数据量场景。应采用自定义分页逻辑，仅查取当前页数据，并根据总记录数分批返回分页接口。
结合键值记忆与自定义分页，还可以设计缓存机制，加速热门页访问，减少数据库压力。
6. 实践建议与适用场景参考
小数据量、页数不高：使用 OFFSET…FETCH 简洁明了，性能可接受。
中等数据量、频繁前几页翻页：Keyset 分页与范围查询是首选。
深度分页（数万页或跳转尾页）：务必拿分页键跳转，避免 OFFSET，大幅提升性能。
查询字段固定、数据稳定：可使用覆盖索引配合 Keyset 分页，最优组合。
高并发环境下：需结合缓存、统计总数的策略设计分页响应机制。
总结
SQL Server 分页查询的性能差异很大，特别在大规模数据与深度分页场景下。OFFSET…FETCH 虽然方便，但不适合深度分页；基于键的分页（Seek/Keyset） 是更高效、安全的选择。有效索引设计、覆盖索引、延迟关联、缓存策略与执行计划分析，是保障分页查询性能的关键。选择合适分页策略，不仅提升用户体验，也降低系统资源消耗，实现高性能、高可扩展的分页服务。