今天准備把項目中用到的分頁功能增加一下,原來的太局限了,於是上網找了一些資料記錄下來,前面的是利用別人總結的,后面是自己測試結果,哈哈,測試要有依據:
建立表:
代碼如下:
[ID] [int] IDENTITY (1, 1) NOT NULL ,
[FirstName] [nvarchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,
[LastName] [nvarchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,
[Country] [nvarchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,
[Note] [nvarchar] (2000) COLLATE Chinese_PRC_CI_AS NULL
) ON [PRIMARY]
GO
插入數據:(20萬條,用更多的數據測試會明顯一些)
SET IDENTITY_INSERT TestTable ON
declare @i int
set @i=1
while @i<=200000
begin
insert into TestTable([id], FirstName, LastName, Country,Note) values(@i, 'FirstName_XXX','LastName_XXX','Country_XXX','Note_XXX')
set @i=@i+1
end
SET IDENTITY_INSERT TestTable OFF
分頁方案一:(利用Not In和SELECT TOP分頁)
語句形式:
代碼如下:
FROM TestTable
WHERE (ID NOT IN
(SELECT TOP 20 id
FROM TestTable
ORDER BY id))
ORDER BY ID
SELECT TOP 頁大小 *
FROM TestTable
WHERE (ID NOT IN
(SELECT TOP 頁大小*頁數 id
FROM 表
ORDER BY id))
ORDER BY ID
分頁方案二:(利用ID大於多少和SELECT TOP分頁)
語句形式:
代碼如下:
FROM TestTable
WHERE (ID >
(SELECT MAX(id)
FROM (SELECT TOP 20 id
FROM TestTable
ORDER BY id) AS T))
ORDER BY ID
SELECT TOP 頁大小 *
FROM TestTable
WHERE (ID >
(SELECT MAX(id)
FROM (SELECT TOP 頁大小*頁數 id
FROM 表
ORDER BY id) AS T))
ORDER BY ID
分頁方案三:(利用SQL的游標存儲過程分頁)
代碼如下:
@sqlstr nvarchar(4000), --查詢字符串
@currentpage int, --第N頁
@pagesize int --每頁行數
as
set nocount on
declare @P1 int, --P1是游標的id
@rowcount int
exec sp_cursoropen @P1 output,@sqlstr,@scrollopt=1,@ccopt=1,@rowcount=@rowcount output
select ceiling(1.0*@rowcount/@pagesize) as 總頁數--,@rowcount as 總行數,@currentpage as 當前頁
set @currentpage=(@currentpage-1)*@pagesize+1
exec sp_cursorfetch @P1,16,@currentpage,@pagesize
exec sp_cursorclose @P1
set nocount off
其它的方案:如果沒有主鍵,可以用臨時表,也可以用方案三做,但是效率會低。
建議優化的時候,加上主鍵和索引,查詢效率會提高。
通過SQL 查詢分析器,顯示比較:我的結論是:
分頁方案二:(利用ID大於多少和SELECT TOP分頁)效率最高,需要拼接SQL語句
分頁方案一:(利用Not In和SELECT TOP分頁) 效率次之,需要拼接SQL語句
分頁方案三:(利用SQL的游標存儲過程分頁) 效率最差,但是最為通用
在實際情況中,要具體分析。
以上是別人寫的文章,在這里我作為保存一下,防止以后原文找不到了,下面就是自己寫的:
我只是測試了第二種和第三種方案,發現第二種方案確實很快,隨着數據的增加,相差不是一個數量級的,曾經在一本書上看到過關於游標的,效率確實不如直接執行sql的,方案二在用的時候需要注意id,這里的id是自增的,如果沒有自增的,就需要引入rownum了。這個時候sql可能會變得更加復雜。
自己結合了方案二寫了一個分頁,因為有些表要是沒有自增長的字段,分頁二實現起來就會有難度,於是自己利用sql server的row_number()函數來實現了一下
SELECT TOP 頁大小 * FROM (select row_number()over(order by ID) as rn,* from TestTable )temTable where rn >= 頁大小*(頁碼-1) and rn <頁大小*頁碼
該語句來自oracle的分頁想法,因為這個可以在程序中封裝,當然了,效率上還是沒有方案二高,而且要求必須要有排序字段。 我測試的數據是95萬條,11個字段。
條件是:where rn > 100000 and rn<101000
自己寫的測試結果:
SQL Server 分析和編譯時間:
CPU 時間 = 3 毫秒,占用時間 = 3 毫秒。
(999 行受影響)
表 'memberlevelglide'。掃描計數 1,邏輯讀取 101196 次,物理讀取 0 次,預讀 0 次,lob 邏輯讀取 0 次,lob 物理讀取 0 次,lob 預讀 0 次。
(8 行受影響)
SQL Server 執行時間:
CPU 時間 = 156 毫秒,占用時間 = 531 毫秒。
SQL Server 分析和編譯時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
SQL Server 執行時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
SQL Server 執行時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
方案二的結果:
SQL Server 分析和編譯時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
(1000 行受影響)
表 'memberlevelglide'。掃描計數 2,邏輯讀取 1205 次,物理讀取 0 次,預讀 0 次,lob 邏輯讀取 0 次,lob 物理讀取 0 次,lob 預讀 0 次。
(9 行受影響)
SQL Server 執行時間:
CPU 時間 = 31 毫秒,占用時間 = 217 毫秒。
SQL Server 分析和編譯時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
SQL Server 執行時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
SQL Server 執行時間:
CPU 時間 = 0 毫秒,占用時間 = 0 毫秒。
參考文獻:http://www.jb51.net/article/35269.htm