Question

我有一个查询，其中包含大约6-7个连接表和一个FREETEXT（）谓词，位于where的基表的6列。

现在，这个查询在过去一年中运行良好（在2秒内）并且几乎保持不变（我尝试旧版本并且问题仍然存在）

所以今天，突然之间，相同的查询大约需要1-1.5分钟。

检查SQL Server 2005中的执行计划后，重建该表的FULLTEXT索引，重新组织FULLTEXT索引，从头开始创建索引，重新启动SQL Server服务，重新启动整个服务器我不知道还有什么尝试。

我暂时将查询切换为使用LIKE，直到我弄明白（现在大约需要6秒）。

当我在查询性能分析器中查看查询时，当我将'FINETEXT'查询与'LIKE'查询进行比较时，前者的读数是读数的350倍（4921261与13943）和20倍（38937 vs 。1938）后者的CPU使用率。

所以'FREETEXT'predicate真的让它变得如此之慢。

有没有人对原因有什么想法？或者我可以做进一步测试？

[编辑]

好吧，我刚刚再次运行查询以获得执行计划，现在它再次需要2-5秒，而不会对其进行任何更改，尽管问题仍然存在于昨天。这不是由于任何外部因素，因为我在上周四第一次测试问题时停止了访问数据库的所有应用程序，因此不是由于任何其他负载。

好吧，我仍然会包含执行计划，虽然现在一切都恢复正常可能没什么帮助...但要注意，这是对遗留数据库的一个巨大查询，我无法改变（即规范化）数据或摆脱一些不必要的中间表）

Query plan

好的，这是完整的query

我可能要解释它究竟是做什么的。基本上，它获取招聘广告的搜索结果，其中有两种类型的广告，高级广告和普通广告。如果有足够的结果，结果将分页为每页25个结果，10个高级结果，之后15个正常结果。

所以有两个内部查询根据需要选择多个优质/正常的查询（例如，在第10页上，它获取前100个优质和前150个正常），然后这两个查询与row_number（）命令交错和一些数学。然后组合按rownumber排序并返回查询。好吧，它在另一个地方用于获取当前页面所需的25个广告。

哦，整个查询是在一个巨大的传统Coldfusion文件中构建的，因为它工作正常，我到目前为止还没有敢于改变大部分...从不接触正在运行的系统等等;）只是小比如更改中心where子句的内容。

该文件还会生成基本相同的其他查询，但没有溢价/非溢价区别以及此查询的许多其他变体，所以我不确定如何更改其中一个可能会更改其他...

好的，因为这个问题没有再次出现，我给了马丁赏金，因为他是迄今为止最有帮助的，我不想让赏金不必要地到期。感谢其他人的努力，如果再次发生，我会尝试你的建议：）

Answer 1

由于全文查询将返回的结果数量基数较差导致JOIN操作的策略较差，因此可能会出现此问题。

如果将其分为两个步骤，您如何找到性能？

使用全文查询的结果填充临时表或表变量的新步骤，第二步更改现有查询以引用临时表。

（注意：您可能想要使用和不使用OPTION(RECOMPILE)尝试此JOIN，同时查看（A）返回许多结果的自由文本搜索字词的查询计划（B）只返回少量结果。）

编辑在没有违规查询的情况下很难澄清，但我的意思是代替做

SELECT <col-list>
FROM --Some 6 table Join
WHERE FREETEXT(...);

这是如何表现的？

DECLARE @Table TABLE
(
<pk-col-list>
)
INSERT INTO @Table
SELECT PK
FROM YourTable
WHERE FREETEXT(...)

SELECT <col-list>
FROM --Some 6 table Join including onto @Table
OPTION(RECOMPILE)

Answer 2

通常当我们遇到这个问题时，是因为表碎片和有问题的索引的陈旧统计数据。

下次，在重建/重新索引后尝试执行sp_updatestats。

有关详细信息，请参阅Using Statistics to Improve Query Performance。

SQL Server 2005 FREE TEXT（）性能问题

2 个答案: