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 

このクエリは数日前に正常に機能しなくなりました。完全には具体化されていませんが、Property CacheとMaster Indexの間のやりとりが適切に機能していないようです。

1）SCOPEパラメータを削除する（つまり、 "FROM SCOPE ）」句

2 FROM）WHERE句（とあるように）

をSCOPE機能を保つことを除いて、私がすることができます 『』コンテンツだけか、単にロケールによってではなく、することによりすることにより、所望の文書を検索します両方を一緒に使って

1つのオプションはカタログを再インデックスすることですが、インデックスの再インデックス付けは今のところ最後の手段です。

は言われていること、私が指定した範囲を除外するようにクエリを書き直し、追加のWHERE句が含ま：検索するとき

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

このクエリは、適切な文書を返します。しかし、私はLIKEキーワードを使用して潜在的なパフォーマンスヒットを懸念していました。そこで、私は各クエリの実行計画を調査しましたが、まったく同じものでした...どちらが私に2つのことを教えてくれるのですか？

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

null値が問題になることがあります。この正確なケースについてはわかりませんが、時には "where xxx is not null"を含むと実際の違いが生まれます。

別のオプションは、開いているクエリの後にテーブルの条件を置くことです。 select aaa, bbb from openquery(.....) where aaa = zzz。 （スタイルを改善するには、*の代わりに必要な列を選択します。

SQL管理のデフォルトメッセージで提供されているメトリックを使用できない場合は、より効率的または高速なクエリを簡単なタイミングプロセスでラップし、自分で判断する必要があります。

最後に、クエリが機能し、プロジェクトに設定した標準を破っていない限り、それを使用してください。