“估计的执行次数”虚增

我有一种情况，选择较慢的查询计划而不是较快的查询计划，因为我相信一些不正确的估计。但是，我无法弄清楚错误估计的来源。下面显示的是更快的计划，因为Index Search的估计成本为123，因此未选择该计划。实际上，从实际执行次数和预计执行次数之间的差异可以看出，成本几乎没有那么高。我的理解是，执行次数是由嵌套循环顶部的行数驱动的。正如你所看到的那样，估计的行数是4878，这非常接近实际。但底部输入的估计执行次数是61110，这是关闭的。 FWIW，我用全面扫描更新了所有表格的统计数据，1.22估计行数是正确的（对于每次执行）。“估计的执行次数”虚增

61110号码来自哪里，有什么方法可以解决它？

查询看起来是这样的：

SELECT 
     Top.Pk 
    FROM 
     Top 
     LEFT JOIN Bottom ON Bottom.Fk = Top.Pk 
    WHERE 
     Top.Date < GETUTCDATE() 
     AND Bottom.Fk IS NULL

来源

2016-11-07 James Brantly

我忘了提及，顶部表格是索引视图，以防万一。 –

您需要提供有关实际查询和表格的更多详细信息。统计数据只是基数估计的一个方面。列表中的下一个就是您的搜索和连接条件。一个常见的问题是具有优化程序无法与实际表内容相关联的连接条件，因此您只根据有多少行将匹配的表大小获得即时估算值。另一个问题是一个非常不均匀内容的表，对于所有优化器都知道的情况，真正可能在特定匹配上产生60.000行。 –

在这种情况下，它将加入GUID。顶部表中的PK到底部的FK。这是寻求的唯一预言。关于同质性，我认为这是统计的重点？无论如何，估计的行数是正确的（在特定匹配中没有60,000行结果，有1.22）。问题是估计的执行次数，我认为这是由顶部输入驱动的（根据屏幕截图中嵌套循环的描述）。 –

虽然我还没有完全理解的执行计划正显示出我们在这里，事实证明这个问题的具体的实例可以通过在索引视图中指定WITH (NOEXPAND)来解决，迫使优化器考虑索引视图上的索引（我认为它已经从执行计划中执行，但显然不是）。

来源

2016-11-07 16:22:18

“估计的执行次数”虚增

回答

相关问题