今天深入研究了一下sql server的分页，结果发现我写的性能跟网上的言论有点不太一样 返回
氵帆 发布于2周前
含有三个利用了索引的子查询（查询是否存在），子查询跟分页在同一级
第一个【Row_Number()】的性能表现好像比第二个【OFFSET/FETCH NEXT分页方式】快一些
数据量不大，就是跟我预期的有些差异，想问问大家有没有见解。
我看了一下，好像是子查询的耗时导致的。total Subtree cost 在这三个子查询的时候，第二个上升的比第一个快。
查第二条记录到第三条记录的时候，开销是49%比51%。下面这个图是筛选第6条到第7条数据。开销差距拉开来了。
热忱回答（15）
-
氵帆 VIP0
2周前
啊，研究了一下网上说【ROW_NUMBER() OVER(ORDER BY 】性能差的文章的代码，看起来好像是人家排序排了好几次....
这个行序号生成后本来就应当已经排好顺序了吧，再多排序几次性能肯定差....
0 回复 -
fate sta VIP0
2周前rownumber是大页码差，页码越大性能越差，比如只查第一页性能就很好 ，排序一般用主键为佳
0 回复 -
氵帆 VIP0
2周前
@fate sta：我是直接用联合索引来排序的。
我现在没用大量数据来查...我测过来ROW_NUMBER()在没有子查询的情况下，性能略差，但好像是第一页性能比OFFSET差更多。
哪天整个大量数据的库来试一下吧....执行计划可能不一样吧....
0 回复 -
fate sta VIP0
2周前
不要看执行计划，要看执行时间，我记得执行计划是 offset比较好
0 回复 -
fate sta VIP0
2周前
ROW第一页我记得是比Offet要快的，最后一页ROW比Offset慢，当然也可能微软在高版有过优化
0 回复 -
氵帆 VIP0
2周前
@fate sta：我这个确实是最新版。后面有空再测测吧...
这两个在我的sql语句里，最大的区别就是这两者在执行计划里选择的分页执行点不一样。
ROW在进行子查询前分页了，Offet在子查询后才分页...这
样导致了子查询的耗时在Offet里明显增多了，随着页数增多，耗时增加越多。
0 回复 -
氵帆 VIP0
2周前
@fate sta：大概懂了，使用Offet的时候，子查询放在外层Select，不要跟分页同层，就能加快速度了。
而ROW的可以在内层也不会有影响。
0 回复 -
氵帆 VIP0
2周前
@fate sta：我觉得sugar的分页函数可以优化一下，增加一个返回Queryable的Offet的分页函数（现在Skip和Take联用可以实现ROW的），以便于实现先分页再在Sql里进行其它处理
0 回复 -
fate sta VIP0
2周前
支持offset分页
0 回复 -
fate sta VIP0
2周前
ToOffsetPage
0 回复 -
氵帆 VIP0
2周前
@fate sta：这个我知道，但这个只能在最外层的select上进行分页的吧
0 回复 -
fate sta VIP0
2周前
@氵帆： 明白你的意思
0 回复 -
fate sta VIP0
2周前
Take或者Skip单独应该没有太多需要用offset场景，Take一般是前多少 性能OK ，skip一般用于小数据操作
0 回复 -
fate sta VIP0
2周前
如果要组合用直接用tooffsetpage
0 回复 -
氵帆 VIP0
2周前
好吧~
0 回复