今天深入研究了一下sql server的分页,结果发现我写的性能跟网上的言论有点不太一样 返回

Sql论坛 沟通中
15 705
该叫什么 氵帆 发布于2023/9/12
悬赏:0 飞吻

含有三个利用了索引的子查询(查询是否存在),子查询跟分页在同一级

第一个【Row_Number()】的性能表现好像比第二个【OFFSET/FETCH NEXT分页方式】快一些


数据量不大,就是跟我预期的有些差异,想问问大家有没有见解。

我看了一下,好像是子查询的耗时导致的。total Subtree cost 在这三个子查询的时候,第二个上升的比第一个快。

查第二条记录到第三条记录的时候,开销是49%比51%。下面这个图是筛选第6条到第7条数据。开销差距拉开来了。

有点奇怪的sql查询性能信息.png

热忱回答15

  • 氵帆 氵帆 VIP0
    2023/9/12

    啊,研究了一下网上说【ROW_NUMBER() OVER(ORDER BY 】性能差的文章的代码,看起来好像是人家排序排了好几次....

    这个行序号生成后本来就应当已经排好顺序了吧,再多排序几次性能肯定差....

    0 回复
  • fate sta fate sta VIP0
    2023/9/12

    rownumber是大页码差,页码越大性能越差,比如只查第一页性能就很好 ,排序一般用主键为佳

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/12

    @fate sta:我是直接用联合索引来排序的。

    我现在没用大量数据来查...我测过来ROW_NUMBER()在没有子查询的情况下,性能略差,但好像是第一页性能比OFFSET差更多。

    哪天整个大量数据的库来试一下吧....执行计划可能不一样吧....

    0 回复
  • fate sta fate sta VIP0
    2023/9/12

    不要看执行计划,要看执行时间,我记得执行计划是 offset比较好

    0 回复
  • fate sta fate sta VIP0
    2023/9/12

    ROW第一页我记得是比Offet要快的,最后一页ROW比Offset慢,当然也可能微软在高版有过优化

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/12

    @fate sta:我这个确实是最新版。后面有空再测测吧...

    这两个在我的sql语句里,最大的区别就是这两者在执行计划里选择的分页执行点不一样。

    ROW在进行子查询前分页了,Offet在子查询后才分页...这

    样导致了子查询的耗时在Offet里明显增多了,随着页数增多,耗时增加越多。

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/12

    @fate sta:大概懂了,使用Offet的时候,子查询放在外层Select,不要跟分页同层,就能加快速度了。

    ROW的可以在内层也不会有影响。

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/13

    @fate sta:我觉得sugar的分页函数可以优化一下,增加一个返回Queryable的Offet的分页函数(现在Skip和Take联用可以实现ROW的),以便于实现先分页再在Sql里进行其它处理

    0 回复
  • fate sta fate sta VIP0
    2023/9/13

    支持offset分页

    0 回复
  • fate sta fate sta VIP0
    2023/9/13

    ToOffsetPage

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/13

    @fate sta:这个我知道,但这个只能在最外层的select上进行分页的吧

    0 回复
  • fate sta fate sta VIP0
    2023/9/13

    @氵帆: 明白你的意思

    0 回复
  • fate sta fate sta VIP0
    2023/9/13

    Take或者Skip单独应该没有太多需要用offset场景,Take一般是前多少 性能OK ,skip一般用于小数据操作

    0 回复
  • fate sta fate sta VIP0
    2023/9/13

    如果要组合用直接用tooffsetpage

    0 回复
  • 氵帆 氵帆 VIP0
    2023/9/13

    好吧~

    0 回复