为何会出现大量内存授予请求？并发执行存储过程的技术问询

首先，别急着调整内存分配参数——大量内存授予请求不一定意味着需要给每个查询分配更多内存，咱们得先搞清楚背后的原因，再针对性解决。

先从DMV的关键信息入手 #

你已经用到了sys.dm_exec_query_memory_grants，可以重点关注以下列来定位问题：

SELECT 
    session_id,
    requested_memory_kb,  -- 查询请求的内存大小
    granted_memory_kb,    -- 实际分配给查询的内存
    used_memory_kb,       -- 查询实际使用的内存
    query_hash,           -- 同一存储过程的查询哈希值应该一致
    sql_handle
FROM sys.dm_exec_query_memory_grants

• 如果used_memory_kb远小于requested_memory_kb：说明优化器对内存需求的估算出错了，大概率是统计信息过时导致的——优化器根据旧的统计信息以为需要大量内存，但实际执行时根本用不上这么多，这会造成内存浪费，还会让其他请求排队等待内存分配。
• 如果多个请求的granted_memory_kb都接近requested_memory_kb，且整体内存占用很高：那可能是存储过程里存在内存密集型操作，比如排序（Sort）、哈希连接（Hash Match），这些操作是内存授予的主要触发源。

常见问题排查与优化方向 #

• 检查存储过程的执行计划
  用上面查到的sql_handle或query_hash找到对应的执行计划，重点看这两点：

  • 有没有不必要的排序：比如ORDER BY操作能不能通过创建覆盖索引来避免？这样就不需要额外申请内存做排序了。
  • 是否使用了哈希连接：如果连接的数据集很大，哈希连接会消耗大量内存，能不能换成嵌套循环连接？前提是连接列上有合适的索引。

• 更新统计信息
  过时的统计信息会误导优化器的内存估算，执行下面的语句更新存储过程涉及表的统计信息：

  UPDATE STATISTICS [你的表名] WITH FULLSCAN;
  

  更新后重新执行存储过程，再观察内存授予情况是否改善。

• 评估min memory per query设置
  当前你设置的是1024KB，这个参数是保证每个查询至少能拿到这么多内存，但如果查询实际不需要这么多，设置过高反而会浪费内存——比如一个查询只需要512KB，你强制分配1024KB，并发上来后，能同时运行的查询数量就会减少，导致更多请求排队等待内存。
  反过来，如果查询实际需要的内存确实超过1024KB，那这个设置没问题，但还是要结合实际使用情况判断。

• 检查服务器内存配置
  看看SQL Server的max server memory设置是否合理，有没有其他进程占用了过多系统内存，导致SQL Server可用内存不足，进而引发内存授予请求排队。

总结 #

盲目增加每个查询的内存分配可能会让问题更糟（比如加剧内存浪费、并发排队），先通过上面的步骤找到内存授予过多的根源——是执行计划可以优化，还是统计信息过时，或者是并发压力下的内存竞争，再针对性处理才是最优解。

内容的提问来源于stack exchange，提问作者Sandhya