use*_*507 8 sql-server execution-plan sql-server-2012 tempdb sorting
我有一个长时间运行的查询(有 1 亿行的事实表加入了一些小的暗表然后分组),它溢出到 tempdb,即使(经过一些调整)CE 非常接近实际的行数,请参阅计划:
寻找解释,我注意到以下内存授予信息:
环境:SQL Server 2012 SP1 Enterprise,服务器 RAM 256 GB,SQL Server 最大内存 200 GB,缓冲池大小 42 GB,工作区最大大小 156 GB(GrantedMemory = 156 * 25% ~= 38 GB)
Paste The Plan 上的匿名查询计划
强制哈希匹配聚合(而不是排序 + 流聚合)时,查询始终快 3 - 4 倍。不幸的是,实际查询来自 Cognos,我们无法更改它。
散列聚合计划中没有散列溢出。查询优化器不会选择散列匹配聚合,因为如果我查看散列与流聚合的运算符成本,散列组的 CPU 成本比进行流聚合高 2 - 3 倍。
在流和哈希聚合中,估计的输出行与输入(约 1 亿行)完全相同。
查询使用单个 NC 列存储索引,并且列统计信息都定期更新。
- 这是否意味着无论 CE 有多好,查询都没有机会不溢出?因为查询最大 ram 的上限为 38 GB
考虑到您当前的硬件和 SQL Server 配置,您查询的总内存授予上限为 37GB。
如果无法在查询内存授予的内存分数(该计划中为 0.860743)内执行排序,它将溢出到tempdb。另请注意,此并行排序在 12 个线程之间平均分配查询内存授予的部分,并且无法在运行时重新平衡此分配。
- 查询优化器在构建计划时是否不考虑最大查询内存?(强制哈希匹配聚合将消除排序步骤并显着提高查询性能,不幸的是,实际查询来自 Cognos,我们无法控制它)
是的,确实如此,但仅作为对一般成本计算框架的输入。优化器根据其模型选择看起来最便宜的计划。如果数字错误,则计划选择不太可能是最佳的。
在您的情况下,Stream Aggregate 生成的实际行数明显少于估计值:
当期望更少、更大的组时,优化器倾向于使用哈希聚合(因为每个组在哈希表中占据一个槽位)。关于密度的错误信息导致 Sort + Stream Aggregate 的错误选择。
最好的计划可能是散列连接而不是嵌套循环连接和散列聚合。这应该能够将批处理模式处理扩展到重要的聚合步骤。
SQL Server 2012 在行模式和批处理模式之间的转换非常有限。一旦行模式处理开始,执行引擎就永远不会返回批处理模式(因此行批处理行可以,但批处理行批处理不行)。
- 将 25% 的上限增加到接近 100% 是一个明智的选择吗?(假设可以控制所述服务器访问以限制并发查询请求的数量)
如果要增加此查询的可用内存量,当然可以通过更改资源调控器设置来实现。逐步增加限制,看看你是否能找到一个好的折衷方案。我会警惕过于接近 100%。
如果查询适合计划指南,请尝试HASH GROUP
提示。
从长远来看,升级到 SQL Server 2016 将带来好处,因为更多的操作符可以在批处理模式下执行(包括排序),动态内存授予是可能的,以及......列存储/批处理模式处理方面的大约一千种其他改进。
我可以部分回答你的问题。
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。有没有什么方法可以更好地估计不同值的数量?创建多列统计数据有帮助吗?
如果您无法更改查询,您可以尝试替换视图引用的表,该视图选择您需要的数据,但会更改计划。这在某些情况下会有所帮助,但我想不出在这里应用该技术的方法。
听起来您对该服务器有相当多的控制权,因此您可以尝试创建计划指南。我从来没有这样做过,也从未听过任何人对计划指南有任何积极的评价。
归档时间: |
|
查看次数: |
2700 次 |
最近记录: |