SQL Server 2012 估计的行数与实际相差很大答案

【问题标题】：SQL Server 2012 Estimated Row Numbers Much Different than ActualSQL Server 2012 估计的行数与实际相差很大
【发布时间】：2019-03-21 09:39:13
【问题描述】：

我有一个交叉连接两个表的查询。 TABLE_1 有 15,000 行，TABLE_2 有 50,000 行。在过去大约 10 分钟内运行了一个与此非常相似的查询。现在它在相同的服务器情况下无限期地运行（即没有其他东西在运行），并且非常相似的查询也在无限期地运行。

SELECT A.KEY_1
      ,A.FULL_TEXT_1
      ,B.FULL_TEXT_2
      ,B.KEY_2
      ,MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0) AS confidence
FROM #TABLE_1 A
CROSS JOIN #TABLE_2 B
WHERE MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0) >= 0.9

当我为此查询运行估计的执行计划时，Nested Loops (Inner Join) 节点估计为执行的 96%。估计的行数是 2.18 亿，即使交叉连接表应该会产生 15,000 * 50,000 = 7.5 亿行。当我将INSERT INTO #temp_table 添加到查询的开头时，估计的执行计划将Insert Into 置于97% 并估计行数为2.18 亿。实际上，相似度得分高于 0.9 的匹配应该少于 100 个。

我了解到，估计行数与实际行数的巨大差异会影响性能。我可以做些什么来测试/解决这个问题？

【问题讨论】：

如果不在列列表和 WHERE 子句中使用标量函数，您可能会看到一些性能提升。这篇博文非常有助于解释此处的最佳实践。 databasejournal.com/features/mssql/article.php/3845381/…
临时表中的 7.5 亿行？您真的需要 tempdb 中的这么多数据吗？
估计的执行计划！=实际的执行计划。但要回答您的问题，请查看上次更新统计数据的时间。这就是优化器使用行数来确定内存和 CPU 需求的地方。也许他们需要更新（也许您没有打开自动更新统计信息）
@Sean 7.5 亿来自交叉连接，所以我不认为它实际上在 tempdb 中，但我可能是错的。 15K表是上周创建的一种类型的varchar项，50K表是第二种类型的所有varchar项。
Statistics matter on temp tables too。自然地，您没有向我们展示该单一查询之前的所有工作。

标签： sql sql-server optimization sql-execution-plan

【解决方案1】：

我了解到，估计行数与实际行数的巨大差异会影响性能。我可以做些什么来测试/解决这个问题？

是的，这是真的。它特别影响涉及连接算法、聚合算法和索引的优化。

但您的查询并非如此。您的查询必须执行没有索引的嵌套循环连接。需要比较两个表中的所有值对。算法灵活性很小，（标准）索引也无济于事。

【讨论】：

谢谢 - 所以我能做的不多吗？这只是令人担忧，因为上周较早的查询运行得更快，行数更少。我猜还有其他一些因素/环境变化导致减速……我只是无法确定是什么。
我不这么认为。它必须处理两个表中的每一对行，根据您的计算，它是 7.5 亿行。没有捷径可走。

【解决方案2】：

为了获得更好的性能，请使用minScoreHint parameter。这样可以防止对许多对进行完整的相似性计算并提前退出。

所以这应该运行得更快：

SELECT A.KEY_1
      ,A.FULL_TEXT_1
      ,B.FULL_TEXT_2
      ,B.KEY_2
      ,MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0, 0.9) AS confidence
FROM #TABLE_1 A
CROSS JOIN #TABLE_2 B
WHERE MDS_DB.MDQ.SIMILARITY(A.FULL_TEXT_1,B.FULL_TEXT_2, 2, 0, 0, 0.9) >= 0.9

从文档中不清楚是否包含 0.9 结果。如果不是，则将 0.9 更改为 0.89

【讨论】：

【解决方案3】：

scsimon 提供的链接将帮助您证明它是否是统计数据。自从它快速运行以来，估计值是否发生了显着变化？

并行性浮现在脑海中。如果查询是并行的，但现在不是（例如，如果服务器设置已更改，或统计信息），那么这可能会导致性能显着下降。

【讨论】：

我很感激 - 绝对是一个有用的链接。但是，临时表统计信息正在被正确估计，并且创建它们只有一步。没有更改服务器设置。不幸的是，我没有在上一次迭代中捕获估计值，因为我没有意识到这将是一个问题。