關(guān)于 SQL 在物理服務(wù)器上使用內(nèi)存 (RAM) 存在許多誤解。我聽到的最常見的情況是用戶擔(dān)心服務(wù)器 RAM 即將用完。SQL Server 旨在使用盡可能多的內(nèi)存。唯一的限制是實例設(shè)置為上限（最大內(nèi)存）的內(nèi)存量以及服務(wù)器上實際使用的 RAM 量。
例如，假設(shè)您的 SQL 服務(wù)器僅使用 8GB 內(nèi)存以最佳方式運行，并且服務(wù)器顯示大約 95% 的總 RAM 正在使用中。您可以將機器上的 RAM 加倍，將 SQL 實例的 Max Memory 設(shè)置加倍，然后看著服務(wù)器慢慢回升到 95%。這不一定是問題。SQL 只是根據(jù)給定的內(nèi)容緩存盡可能多的臨時數(shù)據(jù)。
下面是我的快速調(diào)查要點，以確定是否確實存在內(nèi)存問題，或者 SQL Server 是否只是在做它應(yīng)該做的事情：
從實例屬性驗證最大內(nèi)存設(shè)置并將其與服務(wù)器總內(nèi)存進行比較。盡量給出SQL，但是每個環(huán)境不一樣。還有許多因素需要考慮（實例數(shù)量、應(yīng)用程序、工作負載、集群狀態(tài)等）。至少，請確保為操作系統(tǒng)留出一些 GB。此外，確保這臺機器上還有其他任何需要它的東西。
如果您的最大內(nèi)存設(shè)置為 2147483647，請立即更改。這是 SQL 安裝時使用的默認值，告訴它根據(jù)需要使用多少。這可能會導(dǎo)致服務(wù)器上的操作系統(tǒng)和其他應(yīng)用程序出現(xiàn)性能問題，并在遇到瓶頸時減慢一切。
從實例屬性運行內(nèi)置的內(nèi)存消耗報告。要立即查找的健康細節(jié)是高 PLE 值和低內(nèi)存授予待定值。頁面預(yù)期壽命是頁面在釋放以“重用”服務(wù)器上的內(nèi)存之前將在緩沖池中停留的秒數(shù)。一般建議是 300 秒或更長，但當(dāng)服務(wù)器上的 RAM 量較大時，此建議會呈指數(shù)增加。Memory Grants Pending 是等待工作區(qū)內(nèi)存授予的進程數(shù)。零是最好的值，因為它意味著所有運行的東西都能夠以它需要的足夠內(nèi)存量來運行。
運行以下查詢以檢查當(dāng)前內(nèi)存計數(shù)器。第三個結(jié)果集將顯示內(nèi)存更改發(fā)生時的時間戳。留意任何“低”內(nèi)存警報，然后確定如果 SQL 使用了適當(dāng)?shù)臄?shù)量，是否應(yīng)該進一步調(diào)查內(nèi)存壓力。
SQL:
SELECT @@SERVERNAME AS [Server Name]
,total_physical_memory_kb / 1024 AS [Total Physical Memory (MB)]
,available_physical_memory_kb / 1024 AS [Available Physical Memory (MB)]
,total_page_file_kb / 1024 AS [Total Page File Memory (MB)]
,available_page_file_kb / 1024 AS [Available Page File Memory (MB)]
,system_memory_state_desc AS [Available Physical Memory]
,CURRENT_TIMESTAMP AS [Current Date Time]
FROM sys.dm_os_sys_memory
OPTION (RECOMPILE);
GO
SELECT physical_memory_in_use_kb / 1024 AS [Physical Memory In Use (MB)]
,locked_page_allocations_kb / 1024 AS [Locked Page In Memory Allocations (MB)]
,memory_utilization_percentage AS [Memory Utilization Percentage]
,available_commit_limit_kb / 1024 AS [Available Commit Limit (MB)]
,CASE WHEN process_physical_memory_low = 0 THEN ‘No Memory Pressure Detected’ ELSE ‘Memory Low’ END AS ‘Process Physical Memory’
,CASE WHEN process_virtual_memory_low = 0 THEN ‘No Memory Pressure Detected’ ELSE ‘Memory Low’ END AS ‘Process Virtual Memory’
,CURRENT_TIMESTAMP AS [Current Date Time]
FROM sys.dm_os_process_memory
OPTION (RECOMPILE);
GO
WITH RingBuffer
AS (
SELECT CAST(dorb.record AS XML) AS xRecord
,dorb.TIMESTAMP
FROM sys.dm_os_ring_buffers AS dorb
WHERE dorb.ring_buffer_type = ‘RING_BUFFER_RESOURCE_MONITOR’
)
SELECT xr.value(‘(ResourceMonitor/Notification)[1]’, ‘varchar(75)’) AS Notification
,CASE
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 1
THEN ‘High Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 2
THEN ‘Low Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 4
THEN ‘Low Virtual Memory Available’
ELSE ‘Physical Memory Available’
END AS ‘Process Memory Status’
,CASE
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 1
THEN ‘High Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 2
THEN ‘Low Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 4
THEN ‘Low Virtual Memory Available’
ELSE ‘Physical Memory Available’
END AS ‘System-Wide Memory Status’
,DATEADD(ms, – 1 * dosi.ms_ticks – rb.TIMESTAMP, GETDATE()) AS NotificationDateTime
FROM RingBuffer AS rb
CROSS APPLY rb.xRecord.nodes(‘Record’) record(xr)
CROSS JOIN sys.dm_os_sys_info AS dosi
ORDER BY NotificationDateTime DESC;
