我們先給出幾種主要的分頁方法和核心語句,然後直接給出結論,有興趣的讀者可以看看後面的數據
幾種常用存儲過程分頁方法
TopN方法
select Top(@PageSize) from TableName where ID Not IN
(Select Top ((@PageIndex-1)*@PageSize) ID from Table Name where .... order by ... )
where .... order by ...
臨時表
declare @indextable table(id int identity(1,1),nid int,PostUserName nvarchar(50))
declare @PageLowerBound int
declare @PageUpperBound int
set @PageLowerBound=(@pageindex-1)*@pagesize--下限
set @PageUpperBound=@PageLowerBound+@pagesize--上限
set rowcount @PageUpperBound
insert into @indextable(nid,PostUserName) select ReplyID,PostUserName from TableName order by ......
select * from TableName p,@indextable t where p.ID=t.nid
and t.id>@PageLowerBound and t.id<=@PageUpperBound order by t.id
CTE--2005新語法,類似臨時表,但是生命周期稍微不同,這裡只是他的一個運用
withcte_temp--定義零時表,PageIndex是一個計算字段,儲存了搜索結果的頁號
As (ceiling((Row_Number() over(order by.... )-1)/@pagesize as int) as PageIndex,* from TableName where.....)
select * fromcte_temp where pageindex=@pageindex-1;
結論:
TopN在小頁數下最快,如果在10頁以下,可以考慮用它,CTE和臨時表時間很穩定,CTE消耗的時間比臨時表多,但是不會引起tempdb的暴漲和IO增加
性能比較
試驗環境:win2003server,Sqlserver2005,庫大小2,567,245行,沒有where子句,試驗時每頁大小50,頁碼作為變量
取0,3,10,31,100,316,1000,3162...頁,也就是10的指數,試驗結果如下
頁數 TopN CTE 臨時表 臨時表 老論壇存儲過程 CTE改進 1 3 12 10 101 457 7302 3 15 7 79 5524 464 7191 10 127 5504 88 3801 464 6116 32 588 9672 122 3601 976 7602 100 4680 9738 166 4235 486 7151 316 45271 9764 323 3867 522 7255 1000 無法計算 9806 869 2578 635 8948 3162 無法計算 9822 2485 4110 12460 8210 10000 無法計算 9754 7812 11926 14250 7359 31623 無法計算 9775 18729 33218 15249 7511 100000 無法計算 無法計算 31538 55569 17139 6124
數據解釋和分析
臨時表分為有沒有緩存兩種時間,CTE就是上面的方法,CTE改進只是把選入CTE臨時表的列數減少了,只選取了頁號和主鍵,Null表示時間無法計算(時間太長),數據單位是毫秒.
從上面的數據可以看到,TopN在前32頁都是有優勢的,但是頁數增大後,性能降低很快,CTE改進比CTE有所進步,平均進步兩秒左右,但是還是比臨時表慢,但是考慮臨時表會增大日志文件的大小,引起大量IO,CTE也就有他自己的優勢,公司現在正在使用的存儲過程效率不錯,但是在頁碼靠後的情況下性能會降低
