小编Chr*_*cht的帖子

根据我阅读的关于 SQL Server 2008 Internals and Troubleshooting（从伊利诺伊州的当地图书馆借来）的书籍，Christian Bolton、Brent Ozar 等。我试图在 SQL Server 上寻求理解和确认，并在网上进行大量搜索，如果有人，我将不胜感激可以确认或更正我的理解。

每个需要查询内存授予的查询或操作都需要工作空间内存。在使用排序、哈希匹配连接、并行（不确定）、批量插入（不确定）、索引重建等的一般查询中，将需要查询工作区内存..

工作区内存是 SQL Server 缓冲池的一部分（它作为缓冲池的一部分分配），最大工作区内存是分配给缓冲池的内存的 75%。默认情况下，单个查询无法获得超过 25% 的工作区内存（在 SQL 2008/SQL 2012 中——由开箱即用的资源调控器默认工作负载组控制）。

寻求确认我的理解

1) 考虑到具有 48 GB RAM 和最大服务器内存配置为 40 GB 的系统，这是否意味着最大工作区内存限制为 30 GB，并且单​​个查询不能获得超过 10 GB 的工作区内存（查询内存）。因此，如果您有一个处理 10 亿行进行大规模散列连接的错误查询，并且需要超过 10 GB 的内存（工作区内存），它甚至会关心通过此内存授予队列或立即溢出到磁盘吗？

2) 如果执行大规模排序操作的查询已分配 5 MB 的工作空间内存，并且在查询的查询执行期间，如果查询优化器意识到由于错误的统计信息或缺少索引，该查询实际上需要30 MB的工作空间内存将立即溢出到 tempdb。即使系统在执行期间有足够的工作空间内存可用，一旦查询在执行期间超过授予的工作空间内存，它也必须溢出到磁盘。我的理解是否正确？

我正在使用Brent Ozar 的sp_Blitz，其结果之一是：

一个查询的多个计划

计划缓存中的单个查询有 1146 个计划 - 这意味着我们可能存在参数化问题。

结果中的链接有这个查询：

SELECT q.PlanCount,
q.DistinctPlanCount,
qs.query_hash,
st.text AS QueryText,
qp.query_plan AS QueryPlan
FROM ( SELECT query_hash,
COUNT(DISTINCT(query_hash)) AS DistinctPlanCount,
COUNT(query_hash) AS PlanCount
FROM sys.dm_exec_query_stats
GROUP BY query_hash
) AS q
JOIN sys.dm_exec_query_stats qs ON q.query_hash = qs.query_hash
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE PlanCount > 1
ORDER BY q.PlanCount DESC, q.query_hash;

...它显示了计划数量最多的查询。

当我运行它时，我得到的最重要的结果之一（对于相同的查询哈希有大约 1150 个计划）让我感到困惑：

也许在屏幕截图上有点难以识别 -这是一个完整的CREATE …