服务器端几种分页方式的性能分析
前言：
本试验在于探讨分页的性能问题，当然客户端分页也是一种分页的策略。不过这种分页方式已经过时了，建议不要采用。这里我们只讨论服务器端分页。
实验环境：
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
