很多人打开任务管理器，看见SQL Server占用内存达到八九十，第一反应就是程序出故障，想着赶紧把占用降下来。这种判断其实不对。SQL Server内存管理逻辑和普通软件差别很大，默认会尽可能占用空闲内存存放缓存数据，属于原生设计，并不是程序bug。浏览器、文本编辑器这类软件，内存用完之后会主动交还系统，SQL Server不会这么操作。它拿到内存用来存放数据页和执行计划，只有操作系统通知内存资源不足，才会释放占用的内存。腾讯云技术文档里写得很清楚，进程占用数值会记录峰值使用量，不会自动回收。所以任务管理器看到内存占满，大多代表实例正常运行，不是故障。
那什么时候才算真正出现故障？核心看内存压力。内存使用率高和内存压力不能混为一谈。内存压力代表现有内存不足以承载当前业务负载，数据页频繁读写交换，查询排队等待内存资源，严重时直接抛出报错信息。微软官方文档记录了多个内存不足相关错误码，701错误“无法配置足够的内存来执行查询”，802错误“无法取得用于在缓冲池中配置页面的内存”是最常见的两类。没有出现这类报错，仅仅任务管理器内存百分比偏高，不用急着调整参数。
判断内存压力，几个指标比任务管理器的百分比靠谱。Page Life Expectancy，简称PLE，用来衡量数据页停留在缓冲池的时长。这个数值持续走低，代表缓存空间不足，系统频繁读取磁盘。还有内存授予等待，排序、哈希类复杂查询需要单独申请内存资源，内存不够时查询就会排队，查询等待统计里会出现RESOURCE_SEMAPHORE信号。还可以直接执行DMV查询，统计各个数据库实际占用内存，阿里云文档提供现成SQL语句，关联sys.dm_os_memory_clerks与sys.databases，就能按数据库维度列出内存占用。结合这几项指标综合判断，远比盯着单一百分比可靠。
确认存在内存压力之后，优先调整max server memory配置项。微软给出建议，给SQL Server设置内存上限，预留一部分内存留给操作系统以及其他程序。预留内存有参考计算公式，通用简化算法：每4GB总内存预留1GB给操作系统，例如16GB服务器，分配给SQL Server最大12GB；32GB服务器分配24GB。也就是1比3的比例，方便记忆。微软还有更精细的计算公式，从整机总内存扣除线程堆栈开销、操作系统所需内存、其他应用占用内存、多页分配器内存，剩余容量才分配给SQL Server。绝大多数场景用简化1比3算法就足够，不需要精细到字节级别。修改方式有两种，SSMS右键服务器属性，找到内存页面填写最大服务器内存；或者运行T-SQL命令调用sp_configure修改。
只修改内存上限远远不够。单纯依靠这一个参数，慢查询依旧会消耗资源。查询层面优化才能从根源缓解问题。索引构建要贴合实际查询语句，WHERE、JOIN、ORDER BY经常引用的列优先建立索引。微软官方问答里提到，索引不要设计得字段过多，宽索引占用内存更大，INSERT、UPDATE、DELETE操作还会额外维护索引，频繁更新的表堆积大量索引反而增加负担。反过来，高频查询缺少合适索引，每次都执行全表扫描，缓冲池被迫缓存大量无效数据页，白白消耗内存。
锁升级是容易被忽略的点。SQL Server执行事务时，会给对应数据行加锁，锁本身也会占用内存。单条语句在同一个数据表获取超过5000个锁，或者锁占用内存达到数据库引擎总内存特定比例，系统自动将行锁升级为表锁。锁升级原本是为减少内存开销，但会造成并发性能暴跌，其他会话全部阻塞。业务存在大批量更新、删除操作，需要检查锁升级触发频率。有时候把一个大事务拆分成多个小批次执行，效果比调整内存参数更好。
执行计划缓存同样需要检查。参数化处理不佳的查询，会生成大量独立执行计划，每一份都会占用内存。一次性计划大量挤占缓存空间，存放业务数据的缓存空间就会被压缩。Query Store适合排查这类问题，记录查询历史、执行计划以及运行指标，定位持续消耗资源的查询。SQL Server 2016版本之后默认开启该功能，可以直接查看。
还有一个需要理清的认知。调低SQL Server内存上限之后性能变差，代表设置数值过低。微软文档写明，max server memory设置过小，会损失性能，实例内部产生内存压力。上限不是越低越好，它的作用只是防止SQL Server耗尽操作系统内存，不是强制压缩内存使用。正常运行的SQL Server实例，内存长期维持八九十，PLE数值稳定，不存在内存相关等待与报错，就是健康状态。重点监控关键指标，不用每天盯着任务管理器内存百分比焦虑。