数据库分页查询
服务器端几种分页方式的性能分析
——bycomaple2011-6-17
前言：
本试验在于探讨分页的性能问题，当然客户端分页也是一种分页的策略。不过这种分页方式已经过时了，建议不要采用。这里我们只讨论服务器端分页。
实验环境：
Pentium（R）[email protected]，2.00GB内存
SqlServer2008数据库环境，数据库中我们要用到的的表：
dbo.GMpipe
CREATETABLE[dbo].[GMpipe](
[GMDataID][uniqueidentifier]NOTNULL,
[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]PRIMARYKEYCLUSTERED
(
[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*FROMdbo.GMpipeORDERBYmeasureTimeDESC
接下来我们就来一起体验一下把：
第一种方式
使用top语句（本文只列出常用的）：
分页的存储过程，已实现好了如下：
CREATEPROCEDUREpaging1
@pageNumINT–-页码
,@NumINT --每页条数
AS
BEGIN
SELECTTOP(@Num)*FROM
(
SELECTTOP(@Num*@pageNum)*FROMdbo.GMpipeORDERBYdbo.GMpipe.measureTimeasc
)bORDERBYb.measureTimeDESC;
END
go
这个中方法先把数据库中的前@Num*@pageNum条数据取出，再从结果集中取出最后的@Num条数据，当然两个排序规则是不一样的这点很重要，不然起不到分页效果。你可以具体试一下就明白了。
看性能
EXECpaging12,5;--每页五条，第十页数据耗时：1s
EXECpaging1200,5;--每页五条，第200页数据耗时：1s
EXECpaging120000,5;--每页五条，第20000页数据耗时：1s
EXECpaging1200000,5;--每页五条，第二十万页数据耗时：3s
第二中方式
使用临时表
分页的存储过程，实现如下：
CREATEPROCEDUREpaging2
@pageNumINT
,@NumINT
AS
BEGIN
SELECTmeasurePipe,measureTime,measureCycle,MeasureData,doseRateValue,IDENTITY(int)NumINTO#tempFROMdbo.GMpipeORDERBYmeasureTimeASC
SELECT*FROM#tempWHERENum<=@Num*@pageNumANDNum>@Num*(@pageNum-1)
ORDERBYNumASC
DROPTABLE#temp
END
Go
这种方式是将表中的数据全部查出，然后加入标识行号的列Num并将其装入临时表#temp中然后可根据行号列进行分页查询。
看性能
EXECpaging22,5;--每页五条，第二页数据耗时：3s
EXECpaging2200,5;--每页五条，第二百页数据耗时：3s
EXECpaging220000,5;--每页五条，第二万页数据耗时：3s
EXECpaging2200000,5;--每页五条，第二十万页数据耗时：3s
第三种方式
采用系统提供的ROW_NUMBER()函数
存储过程实现如下：
CREATEPROCEDUREpaging0
@pageNumINT
,@NumINT
AS
begin
SELECT*FROM
(
SELECTmeasurePipe,measureTime,measureCycle,MeasureData,doseRateValue,ROW_NUMBER()OVER(ORDERBYGMpipe.measureTimeASC)ASNUM
FROMGMpipe)A
WHEREA.NUM<=@Num*@pageNumANDA.NUM>@Num*(@pageNum-1)ORDERBYA.measureTimedesc
END
Go
这种方式就不多说了大家一看就明白，直接看性能。
看性能
EXECpaging020,5;--每页五条，第二十页数据耗时：1s
EXECpaging020000,5;--每页五条，第二万页数据耗时:1s
EXECpaging0200000,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
这样一来执行效率更高了呵呵！
总结
我们再来改变一下每页的条数看看
临时表方式：
EXECpaging25000,200;--每页两百条，第五千页数据耗时：7s
Top语句方式：
EXECpaging15000,200;--每页两百条，第五千页数据耗时：3s
ROW_NUMBER()函数方式：
EXECpaging05000,200;--每页五条，第二十万页数据耗时：1s
分析：这样我们就能看到很清楚了吧，影响top语句方式的因素是你要取的页数，即越靠后耗时也明显。影响临时表的因素则比较多了首先是数据的总条数，其次是分页方式即每页的数据量。而ROW_NUMBER()函数的影响则可能只有总的数据量，并且性能可是不错的哦！
我想对与一般的系统而言二十万页的数据分页量已经够用了吧，呵呵！再多的话我们也看不过来啊