sqlserver關於分頁存儲進程的優化【讓數據庫按我們的意思履行查詢籌劃】。本站提示廣大學習愛好者：（sqlserver關於分頁存儲進程的優化【讓數據庫按我們的意思履行查詢籌劃】）文章只能為提供參考，不一定能成為您想要的結果。以下是sqlserver關於分頁存儲進程的優化【讓數據庫按我們的意思履行查詢籌劃】正文
--代碼一DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT n.* FROM news AS n WITH(NOLOCK), #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize AND t.newsid=n.newsid
SELECT @cc
DROP TABLE #tb
--代碼二
DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT NewsId INTO #tb2 FROM #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize
SELECT * FROM news WITH(NOLOCK) WHERE NewsId IN (SELECT * FROM #tb2)
SELECT @cc
DROP TABLE #tb
DROP TABLE #tb2
謎底是代碼二遠遠高於代碼一。在代碼一中加粗代碼的操作會惹起整表掃描，由於數據庫引擎在以為WHERE表達式中知足前提記載年夜於必定閥值的時刻，就不再去停止查詢優化，而直接應用表掃描。看履行信息，：
表 'news'。掃描計數 1，邏輯讀取 342 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
(98361 行受影響)
(1 行受影響)
(40 行受影響)
表 '#tb________________________________________00000004C024'。掃描計數 1，邏輯讀取 257 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
表 'news'。掃描計數 1，邏輯讀取 2805 次，物理讀取 0 次，預讀 235 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
(1 行受影響)
(1 行受影響)
本來，我想的履行籌劃，加粗部門的代碼應當是聚焦索引查找，如許機能就進步許多。看代碼二：
表 'news'。掃描計數 1，邏輯讀取 342 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
(98361 行受影響)
(1 行受影響)
表 '#tb____________________________________00000004BEEF'。掃描計數 1，邏輯讀取 257 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
(40 行受影響)
(1 行受影響)
(40 行受影響)
表 'news'。掃描計數 0，邏輯讀取 131 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
表 '#tb2___________________________________00000004BEF0'。掃描計數 1，邏輯讀取 2 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
(1 行受影響)
(1 行受影響)
很顯著，代碼二與代碼一中的IO操作數年夜年夜下降。且代碼一跟著@PageIndex愈來愈年夜，效力會愈來愈低；但代碼二的效力不會隨@PageIndex變更而轉變。
