6

バックグラウンド

顧客の地域を表す POLYGONS/MULTIPOLYGONS を含むテーブルがあります。

  • テーブルには約 8,000 行が含まれています
  • ポリゴンの約 90% が円
  • ポリゴンの残りの部分は、1 つ以上の州、県、またはその他の地理的地域を表します。これらのシェイプの生のポリゴン データは、米国の国勢調査データからインポートされました。
  • テーブルには、主キーに空間インデックスとクラスター化インデックスがあります。デフォルトの SQL Server 2008 R2 設定は変更されていません。オブジェクトごとに 16 セル、すべてのレベルが中。

私が経験している問題を再現する簡単なクエリを次に示します。

DECLARE @point GEOGRAPHY = GEOGRAPHY::STGeomFromText('POINT (-76.992188 39.639538)', 4326)

SELECT terr_offc_id
FROM tbl_office_territories
WHERE terr_territory.STIntersects(@point) = 1

単純で単純なクエリのように見えても、実行に 12 ～ 13 秒かかり、そのような単純なクエリに対して非常に複雑な実行計画のように見えます。

実行計画

私の調査では、クエリ オプティマイザーが空間インデックスを適切に使用するように、クエリにインデックス ヒントを追加することをいくつかの情報源が提案しています。追加WITH(INDEX(idx_terr_territory))しても効果はなく、実行計画から、ヒントに関係なくインデックスを参照していることは明らかです。

ポリゴンの削減

米国国勢調査データからインポートされた地域ポリゴンが不必要に複雑である可能性があるように思われたため、2 番目の列を作成し、さまざまな許容度で縮小ポリゴン ( Reduce() メソッドを使用) をテストしました。新しい列に対して上記と同じクエリを実行すると、次の結果が得られました。

  • 削減なし: 12649ms
  • 10 減: 7194ms
  • 20 減: 6077ms
  • 30 減: 4793ms
  • 40 減: 4397ms
  • 50 減: 4290ms

明らかに正しい方向に向かっていますが、精度を落とすことは洗練されていない解決策のように思えます。これは、インデックスが想定されているものではありませんか? そして、そのような基本的なクエリの実行計画は、依然として奇妙に複雑に見えます。

空間インデックス

好奇心から、空間インデックスを削除したところ、結果に驚かされました。

  1. クエリは、インデックスなしで高速になりました (削減なしで 3 秒未満、削減許容値 >= 30 で 1 秒未満)
  2. 実行計画ははるかに単純に見えました。

インデックスなしの実行計画

私の質問

  1. 空間インデックスによって速度が低下するのはなぜですか?
  2. クエリを高速化するために、ポリゴンの複雑さを軽減することは本当に必要ですか? 精度を落とすと、将来的に問題が発生する可能性があり、うまくスケーリングできないようです。

その他の注意事項

  • SQL Server 2008 R2 Service Pack 1 が適用されました
  • さらなる調査により、ストアド プロシージャ内でクエリを実行することが提案されました。これを試してみましたが、何も変わらないように見えました。
4

2 に答える 2

0

これは、単純な実行計画が並行して実行されていることに起因している可能性がありますが、他の実行計画はそうではありません。ただし、最初の実行計画には、調査する価値のある警告があります。

于 2013-01-13T21:44:31.223 に答える