查询内存授予和 tempdb 溢出

Question

我有一个长时间运行的查询（有 1 亿行的事实表加入了一些小的暗表然后分组），它溢出到 tempdb，即使（经过一些调整）CE 非常接近实际的行数，请参阅计划：

寻找解释，我注意到以下内存授予信息：

环境：SQL Server 2012 SP1 Enterprise，服务器 RAM 256 GB，SQL Server 最大内存 200 GB，缓冲池大小 42 GB，工作区最大大小 156 GB（GrantedMemory = 156 * 25% ~= 38 GB）

问题

1. 这是否意味着无论 CE 有多好，查询都没有机会不溢出？因为查询最大 ram 的上限为 38 GB
2. 查询优化器在构建计划时是否不考虑最大查询内存？（强制哈希匹配聚合将消除排序步骤并显着提高查询性能，不幸的是，实际查询来自 Cognos，我们无法控制它）
3. 将 25% 的上限增加到接近 100% 是一个明智的选择吗？（假设可以控制所述服务器访问以限制并发查询请求的数量）

Paste The Plan 上的匿名查询计划

强制哈希匹配聚合（而不是排序 + 流聚合）时，查询始终快 3 - 4 倍。不幸的是，实际查询来自 Cognos，我们无法更改它。

散列聚合计划中没有散列溢出。查询优化器不会选择散列匹配聚合，因为如果我查看散列与流聚合的运算符成本，散列组的 CPU 成本比进行流聚合高 2 - 3 倍。

在流和哈希聚合中，估计的输出行与输入（约 1 亿行）完全相同。

查询使用单个 NC 列存储索引，并且列统计信息都定期更新。

Answer 1

1. 这是否意味着无论 CE 有多好，查询都没有机会不溢出？因为查询最大 ram 的上限为 38 GB

考虑到您当前的硬件和 SQL Server 配置，您查询的总内存授予上限为 37GB。

如果无法在查询内存授予的内存分数（该计划中为 0.860743）内执行排序，它将溢出到tempdb。另请注意，此并行排序在 12 个线程之间平均分配查询内存授予的部分，并且无法在运行时重新平衡此分配。

2. 查询优化器在构建计划时是否不考虑最大查询内存？（强制哈希匹配聚合将消除排序步骤并显着提高查询性能，不幸的是，实际查询来自 Cognos，我们无法控制它）

是的，确实如此，但仅作为对一般成本计算框架的输入。优化器根据其模型选择看起来最便宜的计划。如果数字错误，则计划选择不太可能是最佳的。

在您的情况下，Stream Aggregate 生成的实际行数明显少于估计值：

当期望更少、更大的组时，优化器倾向于使用哈希聚合（因为每个组在哈希表中占据一个槽位）。关于密度的错误信息导致 Sort + Stream Aggregate 的错误选择。

最好的计划可能是散列连接而不是嵌套循环连接和散列聚合。这应该能够将批处理模式处理扩展到重要的聚合步骤。

SQL Server 2012 在行模式和批处理模式之间的转换非常有限。一旦行模式处理开始，执行引擎就永远不会返回批处理模式（因此行批处理行可以，但批处理行批处理不行）。

3. 将 25% 的上限增加到接近 100% 是一个明智的选择吗？（假设可以控制所述服务器访问以限制并发查询请求的数量）

如果要增加此查询的可用内存量，当然可以通过更改资源调控器设置来实现。逐步增加限制，看看你是否能找到一个好的折衷方案。我会警惕过于接近 100%。

如果查询适合计划指南，请尝试HASH GROUP提示。

从长远来看，升级到 SQL Server 2016 将带来好处，因为更多的操作符可以在批处理模式下执行（包括排序），动态内存授予是可能的，以及......列存储/批处理模式处理方面的大约一千种其他改进。

Answer 2

我可以部分回答你的问题。

1）我不确定我是否完全理解你的问题。由于基数估计错误，SQL Server 只会溢出到 tempdb，这是不正确的。有时，SQL Server 期望足够好的计划会溢出到 tempdb。

2) 查询优化器在构建计划时确实考虑了服务器上的内存。一个有用的练习可能是更改查询可用的内存量，以查看查询计划如何变化。您可以通过更改服务器上的内存设置、使用资源调控器或未记录的命令DBCC OPTIMIZER WHAT_IF()来实现此目的。如果您想查看内存超过 200 GB 的查询计划是什么样子，那么 WHAT_IF 非常有用。

正如您所指出的，查询优化器不使用哈希匹配聚合，因为它认为该运算符的 CPU 成本将远高于排序。使哈希匹配聚合对优化器有吸引力的标准之一是 SQL Server 估计不会返回许多不同的行。对于您的查询，SQL Server 认为它不会使用 GROUP BY 消除任何行。

计划的估计成本有多接近？当您更改查询可用的内存时，它们会如何变化？

3）我不知道，但这绝对是你应该仔细测试的事情。更安全的选择是增加 SQL Server 最大 ram（200 似乎有点低，但服务器上可能安装了其他应用程序，或者这超出了您的控制范围）或提高 tempdb 性能。我可以想到一些其他提高性能的想法，但它们都不太可能。

尝试运行一个更简单的查询，仅对事实表执行 GROUP BY。有没有什么方法可以更好地估计不同值的数量？创建多列统计数据有帮助吗？

如果您无法更改查询，您可以尝试替换视图引用的表，该视图选择您需要的数据，但会更改计划。这在某些情况下会有所帮助，但我想不出在这里应用该技术的方法。

听起来您对该服务器有相当多的控制权，因此您可以尝试创建计划指南。我从来没有这样做过，也从未听过任何人对计划指南有任何积极的评价。