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两件事情：

1）的索引服务的查询优化组件以这样的方式，以使它们等于两个查询。

2）时，没有DB表中引用的查询分析仪没有远程查询提供准确的反馈。

<强>问题（没有特定的顺序）。没有人有任何见解如下：

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

空值可能是一个问题。我不知道这个确切的情况下，但有时包括“where xxx is not null”可以发挥重要的作用。

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

至于这是更有效的或更快，可能必须用一个简单的定时过程，并判断为自己包裹查询如果不能使用由SQL管理默认消息提供的度量。

在最后，只要你的查询工作，并不会破坏你已经设置为你的项目的任何标准，是的 - 使用它。