zoukankan      html  css  js  c++  java
  • 服务器端几种分页方式的性能分析

    前言:

    本试验在于探讨分页的性能问题,当然客户端分页也是一种分页的策略。不过这种分页方式已经过时了,建议不要采用。这里我们只讨论服务器端分页。

    实验环境:

    Pentium(R) dual-Core CPU E5300 @ 2.6GHz 2.59GHz, 2.00GB内存

    SqlServer2008 数据库环境,数据库中我们要用到的的表: 

    dbo.GMpipe

    CREATE TABLE [dbo].[GMpipe](

    [GMDataID] [uniqueidentifier] NOT NULL,

    [pointID] [uniqueidentifier] NULL,

    [measurePipe] [varchar](10) NULL,

    [measureTime] [datetime] NULL,

    [measureCycle] [varchar](10) NULL,

    [MeasureData] [int] NULL,

    [doseRateValue] [decimal](18, 10) NULL,

     CONSTRAINT [PK_GMPIPE] PRIMARY KEY CLUSTERED 

    (

    [GMDataID] ASC

    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

    ) ON [PRIMARY]

    目前该表中存在1157226条数据,用select语句查询耗时为:17s

    SELECT  * FROM dbo.GMpipe ORDER BY measureTime DESC

     

    接下来我们就来一起体验一下把:

    第一种方式

    使用top语句(本文只列出常用的):

    分页的存储过程,已实现好了如下:

    CREATE PROCEDURE paging1

     @pageNum INT -页码

     ,@Num INT    --每页条数

    AS

    BEGIN

    SELECT TOP (@Num) *  FROM 

    (

    SELECT TOP (@Num*@pageNum) * FROM dbo.GMpipe ORDER BY dbo.GMpipe.measureTime asc

    ) b ORDER BY b.measureTime DESC;

    END

    go

    这个中方法先把数据库中的前@Num*@pageNum条数据取出,再从结果集中取出最后的@Num条数据,当然两个排序规则是不一样的这点很重要,不然起不到分页效果。 你可以具体试一下就明白了。

    看性能

    EXEC paging1 2,5;--每页五条,第十页数据 耗时:1s

    EXEC paging1 200,5;--每页五条,第200页数据 耗时:1s

    EXEC paging1 20000,5;--每页五条,第20000页数据 耗时:1s

    EXEC paging1 200000,5;--每页五条,第二十万页数据 耗时: 3s

    第二中方式

    使用临时表

    分页的存储过程,实现如下:

    CREATE PROCEDURE paging2

     @pageNum INT

    ,@Num INT

    AS

    BEGIN

    SELECT  measurePipe,measureTime,measureCycle,MeasureData,doseRateValue,IDENTITY(int) Num INTO #temp FROM dbo.GMpipe ORDER BY measureTime ASC 

    SELECT * FROM #temp WHERE  Num<=@Num*@pageNum AND Num> @Num*(@pageNum-1)

    ORDER BY Num ASC

    DROP TABLE #temp

    END

    Go

    这种方式是将表中的数据全部查出,然后加入标识行号的列Num并将其装入临时表#temp中然后可根据行号列进行分页查询。

    看性能

    EXEC paging2 2,5;--每页五条,第二页数据 耗时:3s

    EXEC paging2 200,5;--每页五条,第二页数据 耗时:3s

    EXEC paging2 20000,5;--每页五条,第二页数据 耗时:3s

    EXEC paging2 200000,5;--每页五条,第二十万页数据 耗时:3s

     

    第三种方式

    采用系统提供的ROW_NUMBER()函数

    存储过程实现如下:

    CREATE PROCEDURE paging0  

     @pageNum INT

     ,@Num INT

     AS 

     begin

    SELECT * FROM 

    (

    SELECT measurePipe,measureTime,measureCycle,MeasureData,doseRateValue,ROW_NUMBER() OVER(ORDER BY  GMpipe.measureTime ASC ) AS NUM 

    FROM GMpipe)A

    WHERE A.NUM<=@Num*@pageNum AND A.NUM> @Num*(@pageNum-1) ORDER BY A.measureTime desc

    END

    Go

    这种方式就不多说了大家一看就明白,直接看性能。

    看性能

    EXEC paging0 20,5;--每页五条,第二十页数据 耗时: 1s

    EXEC paging0 20000,5;--每页五条,第二页数据 耗时: 1s

    EXEC paging0 200000,5;--每页五条,第二十万页数据 耗时: 1s
    改进第三种方式:

     之所以要改进第三种方式那是因为,Top关键字其实是

    已经经过性能优化了的之所以比不过ROW_NUMBER()的执行效率是因为用了两次,那么既然如此,我们何不将二者结合起来使用,效果岂不更佳。那就让我们改进一下吧。

     

    CREATE PROCEDURE paging0

    @pageNum INT

    ,@Num INT

    AS

    begin

    SELECT * FROM

    (

    SELECT TOP (@Num*@pageNum)  measurePipe,measureTime,measureCycle,MeasureData,

              doseRateValue,ROW_NUMBER() OVER(ORDER BY GMpipe.measureTime ASC ) AS NUM

    FROM GMpipe)A

    WHERE A.NUM> @Num*(@pageNum-1) ORDER BY A.measureTime desc

    END

    Go

     这样一来执行效率更高了呵呵!

     

    总结

    我们再来改变一下每页的条数看看

    临时表方式:

    EXEC paging2 5000,200;--每页两百条,第五千页数据 耗时:7s

    Top语句方式:

    EXEC paging1 5000,200;-- 每页两百条,第五千页数据 耗时: 3s

     

    ROW_NUMBER()函数方式:

    EXEC paging0 5000,200;--每页五条,第二十万页数据 耗时:1s

     

    分析:这样我们就能看到很清楚了吧,影响top语句方式的因素是你要取的页数,即越靠后耗时也明显。影响临时表的因素则比较多了首先是数据的总条数,其次是分页方式即每页的数据量。而ROW_NUMBER()函数的影响则可能只有总的数据量,并且性能可是不错的哦!

    我想对与一般的系统而言二十万页的数据分页量已经够用了吧,呵呵!再多的话我们也看不过来啊。

    原文出处: http://blog.csdn.net/comaple/article/details/6552431

  • 相关阅读:
    接口测试断言详解(Jmeter)
    接口测试参数化详解(Jmeter)
    记一次线上内存泄漏问题的排查过程
    BI入门经典(转载)
    图形初阶
    数据的输入
    来自 Google 的 R 语言编码风格指南
    提醒程序员注意的一些事项--R
    R语言-attach、detach、with
    R数据类型
  • 原文地址:https://www.cnblogs.com/akwwl/p/3578333.html
Copyright © 2011-2022 走看看