在查询中使用过滤器和CONTAINSTABLE时的执行计划不佳

我们有一个有趣的问题，我希望有人能够帮助解决一些问题。在高层次上的问题如下：在查询中使用过滤器和CONTAINSTABLE时的执行计划不佳

下面的查询快速执行（1秒）：

SELECT SA.* 
FROM cg.SEARCHSERVER_ACTYS AS SA 
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID

，但如果我们添加了一个筛选的查询，则需要大约2分钟返回：

SELECT SA.* 
FROM cg.SEARCHSERVER_ACTYS AS SA 
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID 
WHERE SA.CHG_DATE>'19 Feb 2010'

看着两个查询执行计划，我可以看到，在第二种情况下有两个地方有，它们是行的实际和估计数之间的巨大差异：

1）对于FulltextMatch表值函数，估计值约为22,000行，实际值为2900万行（然后在连接前将其过滤为1670行）和 2）对于索引查找全文索引，其中估计值为1行，实际值为13,000行

由于估计结果，优化器选择使用嵌套循环连接（因为它假定行数很少），因此计划效率低下。

我们可以通过（a）参数化查询并向查询添加OPTION（OPTIMIZE FOR UNKNOWN）或（b）通过强制使用HASH JOIN来解决问题。在这两种情况下，查询都会在1秒内返回，估计似乎是合理的。

我的问题确实是'为什么这些估计值被用在表现不佳的案例中，因此非常不准确，可以采取哪些措施来改善它们'？

统计信息在此处使用的索引视图上的索引是最新的。

任何帮助非常感谢。

来源

2010-04-16 Paul McLoughlin

据我所知，这是SQL Server版本的一个问题。该问题表现在SQL Server 2008中，没有Service Pack。将数据库恢复到具有SP1的计算机上，CU5给出了一个不同的（并且更加高效）的执行计划。 – 2010-04-16 22:00:24

这里的问题原来是SQL Server的版本。该问题表现为SQL Server 2008（不包含Service Pack），并通过升级到SQL Server 2008 SP1（并添加了CU5）解决。由于我们没有测试没有安装CU5，我无法确定修补程序是否附带SP1或CU5。无论如何，问题都解决了。士气？让你的服务器保持最新状态。

来源

2010-06-02 18:58:34

有趣。我有完全相同的问题，但我有最新版本的2008 R2。如果结果集很小，它似乎选择了错误的执行计划。添加OPTION（HASH JOIN）似乎可以解决这个问题，但我对这个问题肯定不够了解。我担心，如果结果集较大，我可能会不必要地放慢速度。它可能是统计数据有问题吗？你怎么看？ – 2010-08-27 11:40:37

如果有人仍在阅读本文，我通过调用'sp_updatestats'来解决我的问题。统计显然不同步。很明显，真的。有可能你有同样的问题，但可能升级SQL Server更新统计信息。 – 2010-11-24 14:38:33

也许你可以在有问题的列上添加一些统计信息 - 这将有助于SQL Server更好地估计行数及其内容。

目前涉及哪些统计或索引？

来源

2010-04-16 19:41:17 SqlRyan

当前正在使用的索引是：索引视图上的聚集索引，它位于UNIQUE_ID列（正在扫描查找大于传入日期的日期），然后是全文索引（对于this unique_id）在CHG_DATE列的索引视图中存在一个索引，但似乎没有被使用。 – 2010-04-16 20:01:24

我可以在这里理解聚集索引的初始索引扫描，但我感到困惑的是全文索引的索引查找 - 这是估计（1行）和实际（13,000）使我最困惑的地方。 – 2010-04-16 20:10:44

在查询中使用过滤器和CONTAINSTABLE时的执行计划不佳

回答

相关问题