更多邏輯讀取但查詢執行在較短時間內

情況1更多邏輯讀取但查詢執行在較短時間內

Table 'lead_transaction'. Scan count 10, logical reads 394, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'appt_master'. Scan count 20, logical reads 4532, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

情況2

Table 'lead_transaction'. Scan count 36466, logical reads 117088, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'appt_master'. Scan count 36466, logical reads 195492, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

在情況1個查詢在4秒內被執行時，用於左連接

在情況2查詢在3秒內執行，使用外部應用，但邏輯讀取非常高。

那麼每個表演有什麼好處？

來源

2014-03-04 AK47

1）什麼是CPU統計？ 2）向我們展示實際查詢，3）發佈查詢計劃（實際） – RBarryYoung

是的。給我一些時間 – AK47

因爲性能只有1秒差異，所以我想知道第二個查詢是否執行得更好，因爲數據已經在緩存中了。您是否嘗試刷新緩存並*然後*查看查詢的性能。 –

由於邏輯讀取來自數據緩存（內存）我會認爲有很多讀取的事實將沒有什麼區別，並且看起來第二個查詢在小型地讀取大量數據時效率更高塊，而第一個查詢以大塊讀取數據。

我很想看看如果物理讀取和邏輯讀取都不會影響性能。

嘗試在運行每個查詢之前清除緩衝區和執行計劃，並查看性能如何。

•DBCC DROPCLEANBUFFERS clears buffer pool 
•DBCC FLUSHPROCINDB clears execution plans for that database

來源

2014-03-27 09:37:02 CathalMF

感謝您的回答，但我仍然不清楚，哪個查詢更好？ – AK47

如果我在我的作品服務器上執行這些命令，它會對任何內容感到擔心嗎？ – AK47

它不會「傷害」任何東西，但它會導致所有查詢運行得更慢，直到緩衝區和緩存重新構建爲止。根據您的LIVE實例的繁忙程度，您可能不想在LIVE上運行它。我建議你研究這兩個函數，並自己決定是否運行它。 – CathalMF

更多邏輯讀取但查詢執行在較短時間內

回答

相關問題