SQLサーバーの空間インデックスのパフォーマンス

約200万レコードのテーブルがあります。境界ボックス以外のデフォルトを使用して、空間インデックスを作成します。一部のクエリは非常に高速で、一部のクエリは非常に低速であることに気付きました。決定要因は、クエリで使用されるポリゴンのサイズに現れます。

より大きな検索エリアでは、を使用WITH(INDEX(SIX_FT5))するとクエリが大幅に遅くなります（0秒から15秒以上）。小さい検索エリアでは、正反対が当てはまります。

以下は、私がテストしているクエリの一部です。

高速：

SELECT TOP(1000) * FROM [FT5] WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

スロー：

SELECT TOP(1000) * FROM [FT5] WITH(INDEX(SIX_FT5)) WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

誰がここで何が起こっているのか知っていますか？

sql-server performance spatial-index

— mdm20
ソース

私はちょうど似たようなものを経験していましたdba.stackexchange.com/questions/61289 / ...先日...テキストからポリゴンを生成していませんでしたが、ポイントとポリゴンが交差していました...空間インデックスを使用するように指定しましたその点で、素晴らしい速度の結果が得られました。次に、ポリゴンの空間インデックスを使用してみましたが、パフォーマンスが非常に悪かったのですが、これは問題の正反対のようです！

— DPSS14年

あなたはそれについて考える場合は、検索封筒のサイズを変更する必要があり、インデックス、遅く応答によって返される複数の行-クエリに大きな影響を持っています。ある時点で、フルテーブルスキャンが高速になり、エンベロープに基づいて行が破棄されます。おそらくインデックスの最適化の余地があるので、空間インデックスオプションを使用する時間を増やすことをお勧めします。

— ビンス14年

あなたの記録はポイントを表していますか？それは述べられていませんでした。また、使用したインデックス作成構文を公開できますか？AutoGridでしたか？

— gischimp

「地理オートガード」と「オブジェクトあたりのセル」= 4000を使用しました。1億以上のポイントと45Kポリゴンの交差。

— マイケル

覚えておく必要があるもう1つのことは、インターセクトは複雑な操作であり、最初にバインドされた要素が交差するかどうかを調べる必要があり、インデックスを介した比較的高速な操作ですが、一致する各アイテムについて、すべてのアイテムが実際に交差するかどうかを計算する必要があることですは別の、よりコストの高い操作であり、ポリゴンがより複雑になり、かつ/またはより多くなるとさらにコストが高くなります。

— AKK2

以下のよう@Vinceによってコメント：

考えてみると、検索エンベロープのサイズを変更すると、クエリに大きな影響があります。インデックスを介して返される行が多くなるほど、応答が遅くなります。ある時点で、フルテーブルスキャンが高速になり、エンベロープに基づいて行が破棄されます。おそらくインデックスの最適化の余地があるので、空間インデックスオプションを使用する時間を増やすことをお勧めします。

— ポリジオ
ソース