7

現在、Lat / Long float列を含むテーブルと、これら2つの列のインデックスと取得する必要のある別の列があるサイトがあります。

私は常にこのテーブルをクエリして、特定のポイントから半径内にある行を取得しています（実際には速度のために正方形を取得しています）が、すでにインデックスが作成されているフィールドのみが必要なので、このインデックスは実際にカバーしています、および実行プランには2つのステップしかありません。

Index Seek  (cost: 100%) and SELECT (cost: 0%)

現在、SQL 2008の空間機能を利用しようとしています。地理列を作成し、それを埋め、空間インデックスを作成しました。

また、実行プランに100万ステップがあり、時間の74％がクラスター化インデックスシークに費やされ、空間インデックスで見つかった行を実際のテーブルに結合して残りを取得することを除いて、すべて正常に機能します。データの...
（空間インデックスシークは実行プランコストの1％を占めます）

したがって、明らかに、Spatialインデックスを適切に使用し、Lat / Longの「通常の」インデックスを使用して、以前よりもはるかに高速に必要なレコードを検索していますが、メインテーブルへの結合はKILLING meであり、Spatialクエリは7倍かかります。私の古いものと同じくらい。

空間インデックスに列を追加して、それがカバーされ、以前と同じように1つのステップで実行できるようにする方法はありますか？
この状況を改善するために私ができる他のことはありますか？

更新：「通常の」インデックスは、INCLUDEキーワードを使用して他の列を「含める」ことができることがわかりました（これは知らなかったので、以前はインデックス自体に列を含めるだけでした）ここ
のドキュメントによると、その句はそうではありません空間インデックスのオプション...何かアイデアはありますか？

ありがとう！
ダニエル

4

1 に答える 1

4

いいえ、残念ながら現在、カバーする空間インデックスを作成する方法はありません。クエリは、行の地理値を取得するために、常にベーステーブルへのブックマークルックアップを実行します。

STIntersectsの場合、実際の地理オブジェクトに対して2次フィルターを実行して、パラメーターオブジェクトと実際に交差していることを確認する必要があるため、これは明らかに常に必要です。ただし、正確な回答を必要とせず、Filter（）を使用できる場合は、ベーステーブルをまったく検索せずに、インデックスから主キー列を提供することができます。これをサポートすることは、次のリリースで検討していることです。

現在のクエリを高速化するという観点から、Filter（）を使用して、sp_help_geography_indexからの出力を使用してインデックスを調整してみましたか？

于 2010-02-23T01:37:43.357 に答える