Question

我们有一个有趣的问题，我希望有人可以帮助解释一下。在较高的层面上，问题如下：

以下查询快速执行（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秒内返回，估算值似乎合理。

我的问题实际上是'为什么在表现不佳的情况下使用的估算非常不准确以及可以采取哪些措施来改善它们？'

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

非常感谢任何帮助。

Answer 1

这里的问题原来是SQL Server的版本。问题表现在SQL Server 2008（没有Service Pack），并通过升级到SQL Server 2008 SP1（并添加CU5）解决了。由于我们没有安装CU5进行测试，因此我无法确定修复程序是SP1还是CU5。无论如何，问题得到了解决。士气？让您的服务器保持最新状态。

Answer 2

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

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

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

2 个答案: