mssql 分頁方式說明:
目前我所知的有以下幾種方式
優缺點分析: 效能最低, 可操作性差
第一種方式和第二種方實際上是比較類似的.
優點: 排序方式比較隨意
缺點:第一種方式 有大量的 io 開銷.
第二種方式則會開銷記憶體, 但當表資料量比較大的時候效能會直線下降.
所以這兩種方式都不適合做大資料量的分頁.
第三種方式: 效能次之, 可操作較差
優點: 排序方式比較隨意
缺點: 資源開銷比較大, 資料庫會承擔不小的運算壓力, 所以也不適合做大表分頁.
第四種方式: 效能平均, 可操作性尚可
優點: 排序相對比較隨意, 各分頁情況下速度平均, 屬於不是最快也不是最慢.
缺點: 沒有明顯缺點.
第五種方式: 效能較好, 可操作性良好
優點: 排序相對比較隨意, **簡潔, 適用面廣.
缺點: 尾頁速度比較慢(需針對優化).
第六種方式: 效能最好, 可操作性比較差
優點: 速度快.
缺點: 尾頁速度比較慢(需針對優化), 對排序鍵有要求.
ps: 以上內容居於以前測試結果說得.
測試用庫 db_pagingtest, 測試用表: paing_new
主鍵: id desc
總記錄 @recordcount: 10000331
分頁尺寸 @pagesize: 30
總頁數 @pagecount: 333345
請求頁 @absolutepage
分頁情況分析:
情況 1:
請求頁等於第一頁, 這種情況是最簡單的.
複製內容到剪貼簿
**:select top @pagesize * from [paing_new] order by id desc
情況 2:
請求頁小於總頁數/2
複製內容到剪貼簿
**:
with cte as
(select top @absolutepage * @pagesize
* row_number() over (order by id desc) as _rownumber
from [paing_new]
)select
* from cte
where _rownumber > (@absolutepage - 1) * @pagesize);
情況 3:
請求頁大於等於總頁數/2
理論上 請求頁等於總頁數/2的時候應該也有優化方法.
複製內容到剪貼簿
**:
with cte as
(select top @recordcount - (@absolutepage - 1) * @pagesize
*, row_number() over (order by id asc) as _rownumber
from [paing_new]
)select
* from cte
where _rownumber > (@recordcount - @absolutepage * @pagesize) order by id desc;
情況 4:
請求頁等於總頁數
複製內容到剪貼簿
**:
with cte as
(select top @recordcount - (@absolutepage - 1) * @pagesize
*, row_number() over (order by id asc) as _rownumber
from [paing_new]
)select
* from cte order by id desc;
資料測試結果:
第 30 條, 即 1 頁, cpu 時間 = 0 毫秒，占用時間 = 1 毫秒, 實際執行時間 = 0 毫秒;
第 1w 條, 即 334 頁, cpu 時間 = 0 毫秒，占用時間 = 3 毫秒, 實際執行時間 = 0 毫秒;
第 10w 條, 即 3334 頁, cpu 時間 = 31 毫秒，占用時間 = 26~28 毫秒, 實際執行時間 = 16~33 毫秒;
第 100w 條, 即 3334 頁, cpu 時間 = 250~260 毫秒，占用時間 = 250~260 毫秒, 實際執行時間 = 250~260 毫秒;
第 5000130 條(中間頁), 即 166671 頁, cpu 時間 = 1200~1300 毫秒，占用時間 = 1200~1300 毫秒, 實際執行時間 = 1200~1300 毫秒;
第 5000160 條(中間頁), 即 166672 頁, cpu 時間 = 3400~3600 毫秒，占用時間 = 3400~3600 毫秒, 實際執行時間 = 3400~3600 毫秒;
第 9000331 條, 即 300012 頁, cpu 時間 = 266~281 毫秒，占用時間 = 273~285 毫秒, 實際執行時間 = 266~296 毫秒;
第 9900331 條, 即 330012 頁, cpu 時間 = 31~32 毫秒，占用時間 = 29~30 毫秒, 實際執行時間 = 30~33 毫秒;
第 9999331 條, 即 333312 頁, cpu 時間 = 0 毫秒，占用時間 = 2~3 毫秒, 實際執行時間 = 0 毫秒;
第 10000331 條(尾頁), 即 333345 頁, cpu 時間 = 0 毫秒，占用時間 = 1 毫秒, 實際執行時間 = 0 毫秒;
ps: 關於時間的說明, cpu 時間和占用時間為 mssql 的統計結果, 實行時間是人為技術所得;
分頁方案優點:
對分頁多數情況進行了針對優化, 並且可以對非主鍵和順序編號等情況進行分頁.
開始和結尾速度都非常快, 因為選擇的記錄集相對較少.
分頁方案缺點:
請求頁在總頁數中間的時候速度比較慢.
結論:對於使用 id 為主鍵索引的分頁, 還是使用傳統的 id 大於或小於這種方式最好.
對於分頁主鍵不明確的, 使用 cte 的方式比較好
SQL Server 2005分頁查詢效能優化
sqlserver2005不支援關鍵字limit 所以它的分頁sql查詢語句將不能用mysql的方式進行，幸好sqlserver2005提供了top，rownumber等關鍵字，這樣就能通過這幾個關鍵字實現分頁。下面是本人在網上查閱到的幾種查詢指令碼的寫法 幾種sqlserver2005高效分頁sq...
MS SQL 2005 最簡單最通用的分頁儲存過程
主要使用mssql的新函式row number實現，我是配合ext.net使用的，記錄下來，以備後用，如有不對，觀迎指正。僅僅是實現了分頁，效率沒有考慮，我也是一mssql新手，所有 就是google組成的。獲取count要select一次，獲取記錄集又select一次，實在不是個好辦法，但我一直沒...
MSSQL2005分割槽表設計步驟
在microsoft sqlserver 2005企業版中提供了分割槽表的功能。分割槽表是指按照資料水平方式分割槽，將資料分布於乙個資料庫的多個不同的檔案組中。mssql2005的表分割槽功能是針對超大型資料庫 從百gb級和tb級 而設計的。通過採取分割槽技術，對於資料子集的執行的維護操作只是針對所...