1

场景：

我正在使用 T-SQL 存储过程（Sql Server Management Studio）使用 MS 索引服务和这个（简化的）查询返回文本文档的搜索匹配：

SELECT * 
FROM openquery( 
  filesystem2, 
  'SELECT 
     Path, Rank, Filename
   FROM 
     SCOPE('' "e:\test\documents" '')
   WHERE 
     CONTAINS('' FORMSOF (INFLECTIONAL, "test" ) '')
   ') b

几天前，此查询停止正常工作。虽然没有完全证实，但属性缓存和主索引之间的交互似乎无法正常工作，因为我可以通过任何一个找到所需的文档，

1）删除SCOPE参数（即仅使用“FROM SCOPE（）”作为FROM子句

2) 删除 WHERE 子句（并保持 SCOPE 函数不变）

因此，我可以仅通过内容或仅通过语言环境“找到”所需的文档，但不能同时使用两者。

一种选择是重新索引目录，但现在重新索引只是最后的选择。

话虽如此，我重写了查询以排除指定的 SCOPE 并包含一个额外的 WHERE 子句：

SELECT * 
FROM openquery( 
  filesystem2, 
  'SELECT 
     Path, Rank, Filename
   FROM 
     SCOPE()
   WHERE 
     CONTAINS('' FORMSOF (INFLECTIONAL, "test" ) '') and 
     Path like ''%e:\test\documents%''
   ') b

此查询在搜索时返回正确的文档。但是，我担心使用 LIKE 关键字可能会影响性能。因此，我调查了每个查询的执行计划，但它们完全相同......这告诉我两件事之一：

1) 索引服务的查询组件以使它们相等的方式优化这两个查询。

2) 查询分析器在没有引用数据库表的情况下，无法为远程查询提供准确的反馈。

问题（不分先后）。有没有人对以下内容有任何见解？：

1) 什么可能导致上述场景中描述的属性缓存和主索引之间的原始问题的行为？

2）关于执行计划，

a) Would the Querying Component process/optimize both queries the same?

b) Can Sql Server Management Studio provide execution plan feedback for openquery queries that do not reference any DB tables?

3) 最后，哪个查询更高效/更快，为什么？

a) i.e. should I use the second one because it solves my problem?

谢谢！

4

1 回答 1

2

null值可能是个问题。我不确定这个确切的情况，但有时包括 " where xxx is not null" 可以产生真正的影响。

有时另一种选择是在打开查询之后将 where 条件放在表上 select aaa, bbb from openquery(.....) where aaa = zzz。（为了更好的风格，选择你需要的列而不是 *.

至于哪个更高效或更快，您可能必须用一个简单的计时过程来包装查询，并自行判断是否无法使用 SQL 管理默认消息提供的指标。

In the end, as long as your query works and does not break any standards that you have set for your project, yes - use it.

于 2009-06-05T19:14:18.130 回答