Sql Server分页查询技巧对比：高效实现与性能选择，数据库分页方案详解

在SQL Server中，利用OFFSET-FETCH子句是进行分页查询最直接高效的方法，尤其是在SQL Server 2012及更高版本中，其语句简洁，性能通常优于传统的ROW_NUMBER()方式。

从简单到复杂的分页方案

最早进行分页查询，很多人会用TOP子句，比如查询前10条记录。但要查询第11到20条，就需要复杂的写法，比如用子查询先选出前10条，再从剩下的里选前10条，这种方法逻辑绕，执行效率也不高。后来，ROW_NUMBER()函数用得很多，它给查询结果的每一行加一个行号，然后我们就可以根据行号范围来选择数据。这个方法在SQL Server 2005以后都可以用，很灵活，但写起来还是有点啰嗦。

现代高效的OFFSET-FETCH方法

现在最推荐的是从SQL Server 2012开始支持的OFFSET-FETCH子句。这个语法特别直观，你直接告诉数据库跳过多少条，然后取多少条就行了。比如，你要取第21到30条数据，就写“ORDER BY 某个字段 OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY”。数据库引擎内部会优化这个操作，尤其是在有合适索引的情况下，它的速度很快，代码也清晰易懂。

为什么OFFSET-FETCH通常更好

你可以把OFFSET-FETCH理解成对ROW_NUMBER()方式的一种优化和简化。对于SQL Server来说，处理OFFSET-FETCH时，如果排序的字段上有索引，它能更有效地定位到要跳过的位置，而不是像老方法那样可能需要先计算出所有前面的行。当你要查询的数据页越靠后（比如第1000页），这种性能优势就越明显。当然，任何分页方法在面对超大偏移量时都会变慢，但OFFSET-FETCH是当前平衡了易用性和性能的最佳选择。

关键的性能选择建议

想让分页查询跑得快，光选对方法还不够。最重要的一点是，确保你ORDER BY的那个字段（或字段组合）上有索引。如果没有索引，数据库就要对大量数据进行临时排序，那会非常慢。另一个技巧是，尽量只查询需要的字段，不要用“SELECT *”。返回的列越多，数据量越大，速度自然就慢了。对于非常深的分页（比如跳到几千页之后），如果性能还是不行，可以考虑其他策略，比如记住上一页最后一条记录的值，然后用“WHERE id > 上一页最后ID”这种方式来查下一页。

不同场景下的方案选择

如果你的数据库版本是2012以前，那就只能用ROW_NUMBER()的方法。如果是2012及以后，新项目就统一用OFFSET-FETCH，简单省事。在处理海量数据的分页时，要心里有数，偏移量非常大的查询必然耗时。这时，可以看看业务上是否需要允许用户直接跳转到那么深的页面，也许改成“上一页”、“下一页”的滚动加载模式会更友好，性能也更好。

FAQ

问：SQL Server 2008R2怎么做分页查询？

答：在SQL Server 2008R2中，可以使用ROW_NUMBER()函数来实现。先通过ROW_NUMBER() OVER (ORDER BY 排序字段) 为结果集生成行号，然后将这个查询作为子查询，在外面根据行号范围进行筛选。这是该版本下最标准的分页方法。

问：使用OFFSET FETCH分页时，数据量很大、翻到很后面时速度变慢怎么办？

答：这是深度分页的常见问题。首先，检查ORDER BY的字段是否建立了索引，这是基础优化。其次，可以考虑改变交互方式，例如采用“无限滚动”加载（每次取下一页），而不是提供直接跳转到任意页的功能。在技术层面，可以尝试使用“基于键值”的分页，即记录上一页最后一条记录的排序键值，查询时使用“WHERE 排序键 > 上次最后值”来获取下一页，这通常比使用大的OFFSET值高效得多。

引用来源：本文内容基于微软官方SQL Server文档中关于查询语句的章节，并结合了常见的数据库性能优化实践总结而成。