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功能是）

所以，我可以‘找到’通过刚才的内容或只是语言环境所需的文档，而不是由一起使用。

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

话虽这么说，我重写查询，以排除指定范围，包括一个额外的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”可以产生真正的差异。

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

至于哪个更有效率或更快，您可能必须使用简单的计时过程来包装查询，并自行判断您是否无法使用由SQL管理默认消息提供的指标。最后，只要您的查询有效，并且不会违反您为您的项目设置的任何标准，那么是的 - 使用它。