关于 SQL 在物理服务器上使用内存 (RAM) 存在许多误解。我听到的最常见的情况是用户担心服务器 RAM 即将用完。SQL Server 旨在使用尽可能多的内存。唯一的限制是实例设置为上限（最大内存）的内存量以及服务器上实际使用的 RAM 量。
例如，假设您的 SQL 服务器仅使用 8GB 内存以最佳方式运行，并且服务器显示大约 95% 的总 RAM 正在使用中。您可以将机器上的 RAM 加倍，将 SQL 实例的 Max Memory 设置加倍，然后看着服务器慢慢回升到 95%。这不一定是问题。SQL 只是根据给定的内容缓存尽可能多的临时数据。
下面是我的快速调查要点，以确定是否确实存在内存问题，或者 SQL Server 是否只是在做它应该做的事情：
从实例属性验证最大内存设置并将其与服务器总内存进行比较。尽量给出SQL，但是每个环境不一样。还有许多因素需要考虑（实例数量、应用程序、工作负载、集群状态等）。至少，请确保为操作系统留出一些 GB。此外，确保这台机器上还有其他任何需要它的东西。
如果您的最大内存设置为 2147483647，请立即更改。这是 SQL 安装时使用的默认值，告诉它根据需要使用多少。这可能会导致服务器上的操作系统和其他应用程序出现性能问题，并在遇到瓶颈时减慢一切。
从实例属性运行内置的内存消耗报告。要立即查找的健康细节是高 PLE 值和低内存授予待定值。页面预期寿命是页面在释放以“重用”服务器上的内存之前将在缓冲池中停留的秒数。一般建议是 300 秒或更长，但当服务器上的 RAM 量较大时，此建议会呈指数增加。Memory Grants Pending 是等待工作区内存授予的进程数。零是最好的值，因为它意味着所有运行的东西都能够以它需要的足够内存量来运行。
运行以下查询以检查当前内存计数器。第三个结果集将显示内存更改发生时的时间戳。留意任何“低”内存警报，然后确定如果 SQL 使用了适当的数量，是否应该进一步调查内存压力。
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;
