RAM中的邏輯讀取是否出現在等待統計中或在哪裡？

關於 SQLOS 的執行模型（RUNNING 狀態、RUNNABLE 隊列、WAITER 列表），噹噹前對 RAM 中的頁面進行邏輯讀取時，任務的狀態是什麼？

如果是 WAITER 列表，最普遍的等待類型是什麼？

我可以以某種方式測量這種操作所需的時間嗎？

我知道大量邏輯讀取會減慢您的查詢速度，大量表/索引掃描（已位於緩衝池中）會減慢您的查詢速度 - 我只想知道它們如何出現在統計資訊/dmv 中或如何將其與其他“經典”等待類型。

當工人​​需要等待某種資源時，它會進入服務員名單。沒有資源可以等待邏輯讀取。假設您的緩衝池尚未分頁，則數據已在 SQL Server 管理的記憶體中。執行大量邏輯讀取的查詢很慢，因為它們花費大量 CPU 來執行這些邏輯讀取。

如果您想了解 SQL Server 在執行邏輯讀取時執行的內部操作，則可以在執行受邏輯讀取瓶頸的查詢時使用perfview或其他工具進行 ETW 跟踪。如果您認為您的工作負載存在記憶體吞吐量問題，ETW 跟踪可能是一個很好的步驟。請注意，情況可能並非如此，以下展示幾乎可以肯定是處理查詢性能問題的錯誤方法。

首先，我將編寫一個查詢，我希望大部分時間都在進行邏輯讀取：

DROP TABLE IF EXISTS #215016;

SELECT 1 ID, REPLICATE('Z', 1000) FILLER INTO #215016
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

SELECT t1.ID, t2.ID
FROM #215016 t1
INNER JOIN #215016 t2 ON t1.ID < t2.ID
OPTION (MAXDOP 1, QueryRuleOff BuildSpool);

SQL Server 在整個查詢執行過程中使用了完整的 CPU 核心。以下是從 10 秒樣本中獲取的 perfview 結果：

也許你對帶圓圈的方法名稱感興趣。對於這個查詢，SQL Server 將大約 5% 的 CPU 時間花在 上sqlmin!BPool::Get，我認為這與實際執行邏輯讀取有關。為了捍衛這個想法，這種方法在sqlmin!BUF::AcquireLatch大多數情況下都是這樣呼叫的：

並且在查詢期間採用的共享鎖存器的數量與邏輯讀取的數量大致相同。但這只是一個猜測，因為 Microsoft 沒有記錄方法名稱，而且我不知道“邏輯讀取”的全部範圍。

引用自：https://dba.stackexchange.com/questions/215016