1

重心を内部に収まるポリゴンと一致させようとする大規模なクエリがあります。ブロックとポリゴンのZ値で制約しますが、それでも多くのポイントインポリ計算を実行し、実行に長い時間がかかります。

いくつかの背景について:

  • 図心を含むテーブルには250万行あります
  • 表のすべての空間データは世界の非常に小さな領域にあり、全体の境界ボックスはわずか7643x2351メートルです。
  • それらの行のうち、660KフィットはZ基準に一致します
  • ポリゴンを含むテーブルには10K行があります
  • 表のすべての空間データは、世界のさらに小さな領域にあります
  • それらの行のうち、2366は名前の基準に一致します
  • インデックスなしでクエリを実行すると11時間かかり、91Kの一致が返されます

クエリは次のようなものです。

select blocks.Id, blocks.WGS84Centroid, polygons.Shape
from 
blocks inner join polygons
    on
    blocks.ZCentre >= (polygons.ZCentre - (polygons.ZLength/2))  and blocks.ZCentre <= (polygons.ZCentre + (polygons.ZLength/2)) and
    polygons.Shape.STIntersects(blocks.WGS84Centroid) = 1
inner join name
    on
    polygons.nameId = name.ID
where name.Name = 'blah'

したがって、このクエリを高速化するために、に空間インデックスを追加しblocks.WGS84Centroid、に1つ追加しましたpolygons.Shape
クエリアナライザは、blocks.Idとblocks.WGS84Centroidを含むblocks.ZCentreの非クラスタ化インデックスも提案しました。

その後、クエリプランは次のようになります。
SSMSクエリプラン

そしてフィルターコスト:
SSMSフィルターのコスト

ただし、これら3つのインデックスを追加した後でも、クエリの実行には同じくらいの時間がかかります。
私は今何ができますか?

4

1 に答える 1

0

空間インデックスがあまり役に立たなかった理由は、おそらく地球のこのような小さな領域のデータの密度に関係していると思います。
私はこれを少し実験しましたが、最良のオプションはインデックスの密度をできるだけ高くすることです。

SQL Server 2008では、これは4つのレベルの空間インデックスグリッドのそれぞれでHIGHを使用することによって行われます。オプティマイザーにこのインデックスを使用するようにほのめかすことで、参加を10時間ではなく1時間にノックダウンしました。

SQL Server 2012で、別の興味深い側面を見つけまし
た。1つ目は、私の場合のように、地理オブジェクトの1つがポイントである場合、STIntersects()がより適切に最適化されることです。私のマシンでは、同じクエリが2008年の2倍の速さで2012年に実行されました。

2番目ははるかに印象的です!2012年の新しいタイプの空間インデックスは、最大8レベルのテッセレーションを使用します。高密度データは、インデックス内のこの幾何学的に高いレベルのテッセレーションに特に適していると思います。これは、同じクエリが、古い4レベルのインデックスではなく新しいインデックスを使用するように示唆された場合に45倍高速に実行されたためです。

于 2012-05-31T08:17:16.860 に答える