SQL Server高邏輯讀取與掃描計數

從性能調優的角度來看哪一個更重要？SQL Server高邏輯讀取與掃描計數

說一個查詢報告有大約200萬條記錄的表上的30次掃描和148次邏輯讀取。

相同查詢的修改版本報告1400次邏輯讀取的1次掃描。第二個查詢需要大約40ms的CPU時間來執行。第二個查詢更好嗎？

我想是這樣，這是我的論文：

在第一種情況下，我們有一個非常大的表大量的掃描。這對CPU和服務器內存來說代價很高，因爲表中的所有行都必須加載到內存中。數千次執行這樣的查詢將對服務器資源徵稅。

在第二種情況下，即使我們正在累積更多的邏輯讀取次數，我們的掃描次數也會減少。由於邏輯讀取實際上對應於從緩存中讀取的頁面數量，因此這裏的瓶頸將是網絡帶寬，以便將結果返回給客戶端。 SQL Server在這種情況下的實際工作量較少。

你的想法是什麼？

來源

2015-02-07 Klaus Nji

堆棧溢出是一個問答網站，因此這個問題是不恰當的，因爲它可能會產生辯論和基於意見的答案。 – 2015-02-08 03:55:41

請確保在運行查詢之前執行'DBCC DOPCLEANBUFFERS'，以便使用冷緩衝區高速緩存測試查詢。否則，你將有誤導性的物理計數掃描結果。 – gotqn 2015-02-08 08:46:10

@GB，我不認爲這是辯論。當然有一種推薦的方法來實現數據庫優化，這正是我所期待的。 – 2015-02-08 15:29:06

邏輯讀取度量標準大多是不相關的。您關心耗費的時間，CPU使用時間和使用的磁盤資源。爲什麼你會關心邏輯讀取？他們通過查看CPU時間來計算。

如果你想讓你的查詢更快地測量掛鐘時間。如果你想使用更少的資源來衡量CPU和物理IO。

來源

2015-02-08 11:42:57 usr

我擔心邏輯讀取的唯一原因是因爲我們的服務操作引起了我們的注意，一些查詢產生了數十億的邏輯讀取並請求查詢優化。我們認爲我們有更多的性能查詢。執行計劃更簡單，CPU時間更短，但在一個表上，邏輯讀取更多。因此，我們需要說服自己，在提出解決方案作爲修復之前，邏輯讀取與性能無關。 – 2015-02-08 15:36:30

然後，您需要高邏輯讀取找到任何問題。具體一點。我不知道有這樣的問題。邏輯讀取在CPU時間度量中考慮。 – usr 2015-02-08 18:54:53

SQL Server高邏輯讀取與掃描計數

回答

相關問題