我有一個查詢，當最初運行需要大約9秒鐘返回並在隨後重新運行約四秒鐘。讀完這些後，我相信這是計劃緩存的一種表現形式（儘管我可能是錯的）。我正試圖優化這個查詢，這個效果讓我很難。
我是否正確分析了這是一個計劃緩存問題還是有其他選擇？如果是這樣，有沒有辦法在本地禁用此緩存（即：對於一個查詢，而不是服務器）。SQL Server緩存
最後，如果可以的話，選項（重新編譯）如何適合這個討論。
我使用SQL Server 2008的方式，
有很多因素在起作用這裏，但一個方式做時避開計劃/數據緩存，在分貝其他負載等，效果查詢優化重點在logical reads。這是需要完成多少次讀取 - 無論它們來自緩存還是不是針對給定的運行都是不相關的。
實施例：
USE AdventureWorks2012;
GO
SET STATISTICS IO ON;
GO
SELECT *
FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;
GO
SET STATISTICS IO OFF;
GO
結果：
Table 'ProductCostHistory'. Scan count 1, logical reads 5, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
當調整該查詢，專注於獲得的邏輯，你可以讀爲低。
它可能不是計劃緩存，但數據緩存是罪魁禍首。有兩種方法可以解決這個問題。 在開發服務器上，您可以運行 DROPCLEANBUFFERS 來清除數據緩存。 您還應該使用查詢計劃和統計信息來執行優化。在這種情況下，您可以使用 SET STATISTICS IO On 並專注於邏輯讀取而不是物理讀取。如果在清除數據高速緩存後運行查詢兩次，則會看到物理讀取數量急劇下降，但邏輯讀取的結果相同。
`OPTION RECOMPILE`
只會影響計劃緩存，只會使情況的不同，其中的查詢計劃本身時的結果集的大小變化顯着變化，由於傳遞不同的參數，例如。
減少邏輯讀取？一般來說，索引和覆蓋索引是浮現在腦海中的。如果你看執行計劃，SQL服務器可能會建議索引，如果它認爲他們需要。它實際上會給你適當的創建索引語法（儘管新索引並不總是有幫助）。同樣在實際執行計劃中，如果返回的行數與預期的行數顯着不同，您可能需要查看統計信息。 SQL服務器維護索引列上的統計信息，但是如果自動統計信息未打開，那麼如果其中的統計信息包含未索引列，那麼您可能需要爲其生成統計信息（或將其索引或打開自動統計信息）。
感謝您的回覆。是否有一些通用技巧和細節可以減少邏輯讀取？ – stas 2012-08-16 17:29:46
我在廣義技術上添加了一個新段落。 – PatFromCanada 2012-08-16 19:10:12
您可以清除使用計劃緩存「FREEPROCCACHE」
爲見this MSDN page和示例如何清除緩存的具體計劃。
這就是說，除非它是一個非常長的SQL語句，否則編譯計劃不會花費4秒鐘，因此最有可能是數據緩存導致您的查詢在第一次執行後運行得更快。
感謝所有的答覆。是否有一些通用技巧和細節可以減少邏輯讀取？ – stas 2012-08-16 17:39:52