Showplan XML中GrantedMemory与MaxQueryMemory的区别及数值解析

先帮你梳理下背景和核心疑问的答案，这个属性确实是Showplan里容易混淆的点：

• 补丁KB3170112给SQL Server 2014、2016的Showplan XML架构新增了MaxQueryMemory属性，它隶属于MemoryGrantInfo节点；
• 到SQL Server 2017及后续版本，这个属性被保留，官方定义为：单个查询允许使用的最大内存（单位：KB）；
• 它和早已存在的GrantedMemory（实际授予查询的内存）、RequestedMemory（查询请求的内存）、RequiredMemory（查询运行的最小内存）共存于Showplan中。

接下来拆解你的核心问题：

一、MaxQueryMemory的数值来源 #

这个数值是查询优化器在编译执行计划时，基于当前SQL Server的内存配置计算出的单查询内存上限，核心逻辑和以下规则/配置相关：

1. 服务器级内存设置：主要参考max server memory（SQL Server缓冲池可使用的最大内存）；
2. 默认分配比例：
   • 当max server memory ≤ 16GB时，单个查询最多可使用缓冲池内存的50%；
   • 当max server memory > 16GB时，单个查询最多可使用缓冲池内存的25%；
   • 这个比例可以通过配置选项max query memory（单位为MB，默认值0表示用系统默认比例）手动调整；
3. 资源调控器限制：如果实例配置了资源调控器，且对目标工作组设置了MAX_MEMORY_PERCENT，MaxQueryMemory会取最严格的上限值。

比如你例子里的295344KB换算成MB是288MB，这意味着当前系统根据内存配置，给单查询划定的内存天花板就是288MB——可能是你的max server memory设置在1GB左右，触发了≤16GB时的50%比例规则，或者有其他自定义限制。

二、MaxQueryMemory的实际含义 #

这个属性本质是当前查询在整个运行周期内能获取的内存资源绝对上限：

• 哪怕查询的RequestedMemory（请求内存）远低于这个值，它也不会被授予超过MaxQueryMemory的内存；
• 如果查询运行中实际需要的内存超过了初始授予的GrantedMemory，但还没到MaxQueryMemory，SQL Server会尝试动态追加内存（前提是系统有剩余内存）；
• 一旦所需内存突破MaxQueryMemory，查询就会被迫把部分数据溢出到tempdb（比如排序、哈希操作的中间结果），这通常会拖慢查询性能。

回到你的例子：RequestedMemory + RequiredMemory = 62864KB是查询预估的总内存需求，但MaxQueryMemory=295344KB是系统给它设定的“内存天花板”——意思是这个查询最多能用到288MB内存，哪怕实际运行中需要更多，也只能靠磁盘临时存储来兜底。

补充：和其他内存属性的区别 #

为了更清晰，整理几个核心内存属性的差异：

• RequiredMemory：查询能正常启动的最小内存阈值，低于这个值查询直接报错；
• RequestedMemory：查询预估的额外内存（比如排序、哈希操作需要的内存），加上RequiredMemory就是查询预估的总内存需求；
• GrantedMemory：SQL Server实际授予查询的内存（通常≥RequiredMemory，可能等于或小于RequestedMemory，取决于系统内存压力）；
• MaxQueryMemory：查询能使用的绝对上限，无论系统内存是否充足，都不能突破这个值。

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