ジオメトリ交差でのカーディナリティ推定が非常に悪い
ポイントをポリゴンのセットと交差させています。クエリにインデックスが付けられ、ポリゴンはオーバーラップしませんが、クエリプランは、1行ではなく18k行を返すと考えているようです。これにより、クエリプランが不適切になります。
特に、クエリプランの右端のノードは、STPointFromText関数が1000のカーディナリティーを返し、このポイントセットとジオメトリインデックスの交点が54k行の30％を返すと考えているようです。 （実際に複数の行を返した反例を見つけることなく、テーブルを100万ポイント実行しました）
この省略されたクエリでは結果はひどいものではありませんが、これの出力を他のものに結合すると、クエリ全体が1行を返しても、カーディナリティの見積もりが高いと、アップストリームテーブルがtablescan + hashmapになります。この拡張クエリは1秒間に数回実行されているので、これをどのように最適化できるのか疑問に思っています。
空間インデックスはHHHHであり、最高解像度（ドメインの最長辺約4000km）が約80x50mの場合、インデックスには56kのポリゴンがあり、予想される最小サイズは約100mです。
est行と実際の行の違いに注意してください。
推定クエリプラン。
行目標をクエリでその役割を果たすようにしたいようです。したがって、おそらくNULLを回避するためのテストを使用してTOP(1)を使用してみてください（SRIDが一致しない場合）。そうすれば、「最近傍」機能を開始できます。Containsを使用していることはわかっていますが、QOに1行しか戻らないことを通知するメソッドを使用したいと考えています。
http://blogs.lobsterpot.com.au/2014/08/14/sql-spatial-getting-nearest-calculations-working-properly/ いくつかのヒントがあるかもしれません...