T-SQL 索引服务 SQL openquery 优化

Question

场景：

我正在使用 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?

谢谢！

Answer 1

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

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

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

最后，只要您的查询有效并且不违反您为项目设置的任何标准，就可以 - 使用它。