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 条件
从 openquery(.....) 中选择 aaa, bbb，其中 aaa = zzz。 （为了更好的风格，选择你需要的列而不是*。

至于哪个更高效或更快，你可能必须用一个简单的计时过程包装查询，并自行判断是否不能使用 。

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