但是,估计会生成大约2.38亿行,导致次优的排序/流聚合策略将数百GB的数据泄漏到tempdb.在这种情况下,逻辑上一致的估计会产生一个Hash Aggregate,删除了溢出,并显着提高了查询性能.
这是sql Server 2014中的错误吗？是否存在低于投入的估计值合理的有效情况？可能有哪些变通方法？
这是full query plan(匿名).我没有sysadmin访问此服务器以提供QUERYTRACEON 2363或类似跟踪标志的输出,但如果它们有用,可能能够从管理员那里获得这些输出.
数据库处于兼容级别120,因此使用新的sql Server 2014基数估算器.
每次加载数据时都会手动更新统计信息.鉴于数据量,我们目前正在使用默认采样率.更高的采样率(或FULLSCAN)可能会产生影响.
解决方法
These “cardinality inconsistencies” can arise in a number of situations,including when concat is used. They can arise because the estimation of a particular subtree in the final plan may have been perfomed on a differently structured but logically equivalent subtree. Due to the statistical nature of cardinality estimation,estimating on different but logically equivalent trees is not guaranteed to get the same estimate. So overall no guarantees of expected consistency are provided.
稍微扩展一下：我想解释它的方式是说初始基数估计(在基于成本的优化开始之前执行)产生更“一致”的基数估计,因为整个初始树被处理,随后每个估计直接取决于前一个.
在基于成本的优化期间,可以探索计划树的一部分(一个或多个操作符)并用替代方案替换,每个替代方案可能需要新的基数估计.没有一般的方法可以说哪种估计通常比另一种更好,所以很有可能最终得出一个看似“不一致”的最终计划.这只是将“一些计划”拼接在一起形成最终安排的结果.
总而言之,sql Server 2014中引入的新基数估算器(CE)有一些细节上的变化,这使得它比原始CE的情况稍微不那么常见.
除了升级到最新的累积更新并检查启用了4199的优化器修复程序之外,您的主要选项是尝试统计/索引更改(注意缺少索引的警告)和更新,或以不同方式表达查询.目标是获取显示所需行为的计划.然后,例如,可以用计划指南冻结这.
匿名计划使评估细节变得困难,但我也会仔细查看位图,看看它们是“优化”(Opt_Bitmap)还是后期优化(Bitmap).我也对过滤器持怀疑态度.
如果行计数是准确的,那么这似乎是一个可能受益于columnstore的查询.除了通常的好处之外,您可以利用批处理模式运算符的动态内存授予(可能需要trace flag 9389).
