我有一个大约6-7个连接表的查询,而在WHERE表的6列上的Freetext()谓词。

现在,该查询在过去一年(在2秒内)运行良好,并且实际上保持不变(我尝试了旧版本,问题仍然存在)

因此,今天,突然之间,同样的查询大约需要1-1.5分钟。

在检查SQL Server 2005中的执行计划之后,重建该表的完整索引,重组FullText索引,从scratch创建索引,重新启动SQL Server服务,重新启动整个服务器,我不知道要尝试什么。

我暂时切换查询要使用 LIKE 相反,直到我弄清楚这个(现在大约需要6秒钟)。

当我查看查询性能分析仪中的查询时,当我将“ freetext´query与“像质查询”进行比较时,前者的读数是350倍(4921261 vs. 13943)和20次(38937 vs. 1938)后者的CPU使用情况。

因此,确实是``freetext'predice''使它变得如此慢。

有人对可能的原因有任何想法吗?还是我可以做的进一步测试?

编辑

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

好吧,我仍然会包含执行计划,尽管现在一切都恢复了,这可能无济于事……要当心,这是我无法更改的旧数据库的一个巨大查询(即标准化数据或获取数据库摆脱一些未内科的中间桌子)

查询计划

好的,这是完整的 询问

我可能不得不解释它到底有什么作用。基本上,它获得了作业广告的搜索结果,其中有两种类型的广告,高级广告和普通广告。结果分页至每页25个结果,如果有足够的话,则在上面有10个优质的结果和15个正常结果。

因此,有两个内部查询选择尽可能多的优质/普通查询(例如,第10页,它获取了前100个高级质量和前150个普通质量),然后这两个查询与Row_number()命令和一些数学交织在一起。然后由Rownumber订购组合,然后返回查询。好吧,它在另一个地方使用了当前页面所需的25个广告。

哦,整个查询是在一个庞大的旧式冷藏文件中构建的,而且由于它运行良好,到目前为止,我还没有敢于thouch/更换大部分...永远不要触摸运行系统等;)只是像更改之类的小东西中央子句的位。

该文件还会生成其他基本相同的查询,但是没有Premium/Non Premium区别和此查询的许多其他变体,因此我永远不确定其中一个更改可能会改变其他查询。 。

好的,由于问题还没有再次浮出水面,所以我给了马丁赏金,因为他到目前为止一直是最有帮助的,我不希望赏金不必要地到期。感谢其他所有人的努力,如果再次发生,我将尝试您的建议:)

有帮助吗?

解决方案

由于对全文查询将归还的结果数量的基数估算差,因此可能出现此问题,从而导致连接操作的策略不佳。

如果将其分为2个步骤,如何找到性能?

一个新的步骤,该步骤填充了全文查询的结果,第二个填充了临时表或表变量,第二个更改现有查询的结果,以转换为temp表。

(NB:您可能想尝试与此连接 OPTION(RECOMPILE) 同时查看(a)的查询计划(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)

其他提示

通常,当我们遇到这个问题时,这是由于有关索引的表分裂和陈旧的统计数据。

下次,尝试执行 SP_UPDATESTATS 重建/驯鹿之后。

使用统计数据来提高查询性能 有关更多信息。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top