sql 2012以後分頁查詢速度問題

一.SQL Server 2012使用OFFSET/FETCH NEXT分頁，比SQL Server 2005/2008中的RowNumber()有顯著改進。今天特意做了簡單測試，現將過程分享以下：

DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE SET STATISTICS IO ON; SET STATISTICS TIME ON; GO

DECLARE @page INT, @size INT
SELECT @page = 3, @size = 10 ;WITH cte AS ( SELECT TOP (@page * @size) CustomerID, CustomerName, CustomerCity, ROW_NUMBER() OVER(ORDER BY CustomerName ) AS Seq, COUNT(*) OVER(PARTITION BY '') AS Total FROM Customers WHERE CustomerCity IN ('A-City','B-City') ORDER BY CustomerName ASC ) SELECT * FROM cte WHERE seq BETWEEN (@page - 1 ) * @size + 1 AND @page * @size
ORDER BY seq; SELECT
*, COUNT(*) OVER(PARTITION BY '') AS Total FROM Customers WHERE CustomerCity IN ('A-City','B-City') ORDER BY CustomerID OFFSET (@page -1) * @size ROWS FETCH NEXT @size ROWS ONLY; GO

SET STATISTICS IO OFF; SET STATISTICS TIME OFF; GO

結果：

二.統計信息解釋

在平時優化SQL的時候，最長用的就是：SET STATISTICS ON，它能夠用來查看咱們寫的查詢語句到底性能如何，不過，究竟這個性能的指標是怎麼樣的呢？首先須要明白的，就是各項數據的意義。

如下解釋來自MSDN（點擊查看） 

輸出項	含義
Table	表的名稱。
scan count	執行的掃描次數。
logical reads	從數據緩存讀取的頁數。
physical reads	從磁盤讀取的頁數。
read-ahead reads	爲進行查詢而放入緩存的頁數。
lob logical reads	從數據緩存讀取的 text、ntext、image 或大值類型 (varchar(max)、nvarchar(max)、varbinary(max)) 頁的數目。
lob physical reads	從磁盤讀取的 text、ntext、image 或大值類型頁的數目。
lob read-ahead reads	爲進行查詢而放入緩存的 text、ntext、image 或大值類型頁的數目。

如下解釋來自園子裏面的一位大師，嘿嘿（點擊查看原文）

掃描計數(Scan Count)：在查詢中涉及到的表被訪問的次數。在咱們的例子中，其中的表只被訪問了1次，因爲查詢中不包括鏈接命令，這一信息並非十分有用，但若是查詢中包含有一個或多個鏈接，則這一信息是十分有用的。（一個循環外部的表的Scan Count值爲1，但對於一個循環內的表而言，其值爲循環的次數。能夠想象獲得，對於一個循環內的表而言，其Scan Count值越小，它所使用的資源越少，查詢的性能也就越高。所以在調節一個帶鏈接的查詢的性能時，須要關注Scan Count的值，在進行調節時，注意觀察它是增長仍是減小了。）

邏輯讀取(Logical Reads)：這是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的 數據。咱們知道，SQL Server在能夠對任何數據進行操做前，必須首先把數據讀取到其數據緩衝區中。此外，咱們也知道SQL Server什麼時候會從數據緩衝區中讀取數據，並把數據讀取到大小爲8K字節的頁中。那麼Logical Reads的意義是什麼呢？Logical Reads是指SQL Server爲獲得查詢中的結果而必須從數據緩衝區讀取的頁數。在執行查詢時，SQL Server不會讀取比實際需求多或少的數據，所以，當在相同的數據集上執行同一個查詢，獲得的Logical Reads的數字老是相同的。（SQL Server執行查詢時的Logical Reads值每一次這個數值是不會變化的。所以，在進行查詢性能的調節時，這是一個能夠用來衡量你的調節措施是否成功的一個很好的標準。若是 Logical Reads值降低，就代表查詢使用的服務器資源減小，查詢的性能有所提升。若是Logical Reads值增長，則表示調節措施下降了查詢的性能。在其餘條件不變的狀況下，一個查詢使用的邏輯讀越少，其效率就越高，查詢的速度就越快。）

物理讀取(Physical Reads)：物理讀，在執行真正的查詢操做前，SQL Server必須從磁盤上向數據緩衝區中讀取它所須要的數據。在SQL Server開始執行查詢前，它要做的第一件事就是檢查它所須要的數據是否在數據緩衝區中，若是在，就從中讀取，若是不在，SQL Server必須首先將它須要的數據從磁盤上讀到數據緩衝區中。咱們能夠想象獲得，SQL Server在執行物理讀時比執行邏輯讀須要更多的服務器資源。所以，在理想狀況下，咱們應當儘可能避免物理讀操做。下面的這一部分聽起來讓人容易感到糊塗 了。在對查詢的性能進行調節時，能夠忽略物理讀而只專一於邏輯讀。你必定會納悶兒，剛纔不是還說物理讀比邏輯讀須要更多的服務器資源嗎？狀況確實是這樣， SQL Server在執行查詢時所須要的物理讀次數不可能經過性能調節而減小的。減小物理讀的次數是DBA的一項重要工做，但它涉及到整個服務器性能的調節，而 不單單是查詢性能的調節。在進行查詢性能調節時，咱們不能控制數據緩衝區的大小或服務器的忙碌程度以及完成查詢所須要的數據是在數據緩衝區中仍是在磁盤 上，惟一咱們可以控制的數據是獲得查詢結果所須要執行的邏輯讀的次數。所以，在查詢性能的調節中，咱們能夠問心無愧地不理會SET STATISTICS IO命令提供的Physical Read的值。（減小物理讀次數、加快SQL Server運行速度的一種方式是確保服務器的物理內存足夠多。）

預計(Read-Ahead Reads)：與Physical Reads同樣，這個值在查詢性能調節中也沒有什麼用。Read-Ahead Reads表示SQL Server在執行預讀機制時讀取的物理頁。爲了優化其性能，SQL Server在認爲它須要數據以前預先讀取一部分數據，根據SQL Server對數據需求預測的準確程度，預讀的數據頁可能有用，也可能沒用。