MSSQL 2005 分頁分析及優化 MSSQL 分頁方式說明:
目前我所知的有以下幾種方式

• 臨時表
• 表變量
• in, not in
• SET ROWCOUNT
• CTE
• id >, id <

優缺點分析: 性能最低, 可操作性差
第一種方式和第二種方實際上是比較類似的.
優點: 排序方式比較隨意
缺點:
第一種方式 有大量的 IO 開銷.
第二種方式則會開銷內存, 但當表數據量比較大的時候性能會直線下降.
所以這兩種方式都不適合做大數據量的分頁.

第三種方式: 性能次之, 可操作較差
優點: 排序方式比較隨意
缺點: 資源開銷比較大, 數據庫會承擔不小的運算壓力, 所以也不適合做大表分頁.

第四種方式: 性能平均, 可操作性尚可
優點: 排序相對比較隨意, 各分頁情況下速度平均, 屬于不是最快也不是最慢.
缺點: 沒有明顯缺點.

第五種方式: 性能較好, 可操作性良好
優點: 排序相對比較隨意, 代碼簡潔, 適用面廣.
缺點: 尾頁速度比較慢(需針對優化).

第六種方式: 性能最好, 可操作性比較差
優點: 速度快.
缺點: 尾頁速度比較慢(需針對優化), 對排序鍵有要求.

PS: 以上內容居于以前測試結果說得.

測試用庫 DB_PagingTest, 測試用表: Paing_New
主鍵: ID Desc
總記錄 @RecordCount: 10000331
分頁尺寸 @PageSize: 30
總頁數 @PageCount: 333345
請求頁 @AbsolutePage

分頁情況分析:

• @AbsolutePage == 1
• @AbsolutePage < @PageCount/2
• @AbsolutePage >= @PageCount/2
• @AbsolutePage == @PageCount

情況 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 的方式比較好.

轉載于:https://www.cnblogs.com/yanbinboy/archive/2008/05/22/1204487.html

總結

以上是生活随笔為你收集整理的MSSQL 2005 分页分析及优化(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。