4

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

现在，这个查询在去年运行良好（不到 2 秒）并且实际上保持不变（我尝试了旧版本，问题仍然存在）

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

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

我暂时将查询改为使用LIKE，直到我弄清楚（现在大约需要 6 秒）。

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

所以真的是“FREETEXT”谓词导致它如此缓慢。

有没有人对可能的原因有任何想法？或者我可以做进一步的测试？

[编辑]

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

好吧，我仍然会包含执行计划，尽管现在一切都恢复正常了，这可能没有多大帮助......并且要注意，这是对我无法更改的遗留数据库的巨大查询（即规范化数据或获取去掉一些不必要的中间表）

查询计划

好的，这是完整的查询

我可能不得不解释它到底做了什么。基本上它会获取招聘广告的搜索结果，其中有两种类型的广告，高级广告和普通广告。结果被分页为每页 25 个结果，如果有足够的话，顶部有 10 个高级结果，之后是 15 个正常结果。

所以有两个内部查询可以根据需要选择尽可能多的高级/普通查询（例如，在第 10 页上，它获取前 100 个高级查询和前 150 个普通查询），然后这两个查询与 row_number() 命令和一些数学运算交错. 然后组合按行号排序并返回查询。好吧，它在另一个地方被用来获取当前页面所需的 25 个广告。

哦，整个查询是在一个巨大的遗留 Coldfusion 文件中构建的，并且由于它运行良好，到目前为止我还不敢修改/更改大部分内容......永远不要触摸正在运行的系统等等；）只是像改变这样的小东西中央 where 子句的位。

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

好的，由于问题没有再次出现，我给了 Martin 赏金，因为他是迄今为止最有帮助的人，我不希望赏金不必要地过期。感谢其他所有人的努力，如果再次发生，我会尝试您的建议:)

4

2 回答 2

1

此问题可能是由于对全文查询将返回的结果数量的基数估计不佳导致 JOIN 操作的策略不佳。

如果你把它分成两个步骤，你如何找到性能？

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

（注意：您可能想在查看查询计划时尝试使用或不使用此 JOIN，OPTION(RECOMPILE)同时查看 (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)
于 2010-05-31T15:36:07.803 回答
0

通常当我们遇到这个问题时，这是因为表碎片和相关索引上的陈旧统计信息。

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

有关详细信息，请参阅使用统计信息提高查询性能。

于 2010-06-02T22:05:38.837 回答