我们有一个问题,我们希望Stack Overflow的好伙伴可以帮助我们.我们正在运行sql Server 2008 R2,并且在查询中遇到问题,需要很长时间才能在约10万行的中等数据量上运行.我们正在使用CONTAINS来搜索xml文件,并在另一列上使用LIKE来支持领先的通配符.
我们已经重现了以下小问题的问题,大约需要35秒才能运行：
SELECT something FROM table1
WHERE (CONTAINS(TextColumn,'"WhatEver"') OR
DescriptionColumn LIKE '%WhatEver%')
查询计划：
如果我们修改上面的查询以使用UNION,则运行时间从35秒下降到< 1秒.我们想避免使用这种方法来解决问题.
SELECT something FROM table1 WHERE (CONTAINS(TextColumn,'"WhatEver"') UNION (SELECT something FROM table1 WHERE (DescriptionColumn LIKE '%WhatEver%'))
查询计划：
我们使用CONTAINS进行搜索的列是一个类型为image的列,由xml文件组成,大小在1k到20k之间.
我们没有什么好的理论,为什么第一个查询太慢了,所以我们希望有人在这件事上有明智的发言.就我们可以看出,查询计划没有显示任何异常的东西.我们还重建了索引和统计数据.
有没有什么明显的,我们忽视这里？
提前感谢您的时间！
解决方法
为什么使用DescriptionColumn LIKE’％WhatEver％’而不是CONTAINS(DescriptionColumn,’“WhatEver”)？
CONTAINS显然是一个全文谓词,并将使用sql Server全文引擎过滤搜索结果,但是LIKE是一个“正常”的sql Server关键字,因此sql Server将不会使用全文引擎与此相关查询 – 在这种情况下,因为LIKE项以通配符开头sql Server将无法使用任何索引来帮助查询,这将很可能导致表扫描和/或比使用全文引擎更差的性能.
在没有执行计划的情况下难以告知,但是我猜测发生的事情是：
>查询的UNION变体是对table1执行表扫描 – 表扫描不快,但是由于表中的行数相对较少,与之相比较慢(与35s基准相比).
>在查询的OR变体中,sql Server首先使用全文引擎根据CONTAINS进行过滤,然后继续对结果中的每个匹配行执行RDI查找,以基于LIKE谓词进行过滤,但是某些原因sql Server已经大量低估了行数(这可能会发生某些类型的谓词),因此继续执行几个adonad的RDI查找,其结果是非常慢(表扫描将会更快).
要真正了解发生了什么,您需要获得查询计划.
