0 記憶體授予掛起，但低 PLE、高惰性寫入/秒和空閒列表停頓/秒錶示什麼？
我的伺服器記憶體是 100GB，其中 90GB 通過最大記憶體設置分配給 SQL Server。
我正在監視一個有 0 個記憶體授權待處理的 sql 伺服器。這意味著沒有程序在等待記憶體。如果這大於 0，那麼它將指示記憶體壓力，這將在增加 max sql server memory 設置時得到解決。
但是我看到低 PLE（頁面預期壽命）、高惰性寫入/秒和空閒列表停頓/秒。這是否表明記憶體壓力？
記憶體授權只是記憶體的一種使用（記憶體授權，例如排序操作）。它不包括“正常”記憶體使用，例如記憶體數據庫文件中的數據。
似乎您讀取和修改了大量數據，以至於 SQL Server 無法將數據庫的“活動部分”保留在記憶體中。這意味著 SQL Server 將非常頻繁地從記憶體中拋出一些東西，以便為您的查詢引用的數據留出位置（用於您的 SELECT 和修改）。
您具有很高的惰性寫入/秒和空閒列表停頓/秒的事實表明，如果不刪除記憶體中的其他數據（包括自從被帶入記憶體後被修改的數據），就無法滿足需要將數據放入記憶體的查詢。一般來說，CHECKPOINT 會處理這個問題，但是與記憶體大小相比，您的數據周轉率似乎很高，因此檢查點無法應對。
對我來說，這似乎是“添加更多記憶體或調整查詢”情況的經典範例。
正如 Tibor Karaszi 提到的，記憶體授予只是檢查潛在問題的一個參數。我將首先查看 SQL Server 等待統計資訊，以得出任何解決實際問題的路徑。
您可以下載FirstResponderKit並在下面執行：
EXEC sp_BlitzFirst檢查頂部等待統計資訊並查看它們指向的內容，每種等待類型都有連結。
我的猜測是（基於記憶體問題），你可以有等待類型 PAGEIOLATCH_*
您的出發點應該是找到那些執行非常繁重的邏輯讀取的查詢或程序，嘗試通過支持索引來修復它們 - 在大多數情況下都有效。如果您需要更改查詢並且您被允許這樣做 - 請這樣做，但是在將它們提升到生產之前在測試環境中對其進行徹底測試。作為一名 DBA，我的第一個賭注是依賴索引。
根據您的等待類型，您可以相應地接聽電話。以下連結將幫助您朝著正確的方向前進：
https://www.brentozar.com/sql/wait-stats/
您也可以從以下連結執行查詢以直接查找等待統計資訊並採取行動：
https://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
希望這可以幫助。