これは正しくありません。
私には2つの可能性があります：
1）統計がテーブルで古くなっています。インデックスを再構築し、統計を更新します。
2）あなたが言ったように、地理テーブルレコードは多くのページにまたがって大きくなっています（複数のページにまたがる1つのレコードではありませんが、レコードは8Kマークに近いです）。この場合、おかしなことに、クラスター化されたインデックスに別の非クラスター化されたインデックスを作成すると役立つ場合があります。
更新
私はそれがうまくいったことを嬉しく思います。さて、いくつかの説明。
まず第一に、何かが本当に正しくなく、実行プランが奇妙に見える場合は、常に統計を調べてインデックスを再構築します。
クラスター化インデックスの非クラスター化インデックスを作成しても、通常は何のメリットもありませんが、テーブルに多くのレコードがあり、レコードが8Kの制限に近い場合に役立ちます。ご存知のように、SQLはレコードをロードするためにディスクに行くときに8Kページをロードします。同様の方法でインデックスを作成すると、8Kページが読み込まれます。インデックスが4バイト整数であるため、これは、クラスター化されたインデックスを使用する場合、少数のレコードをロードするときに2000レコードのIDをロードすることを意味します（必要なのはJOINビットのIDだけであることに注意してください）。これは二分探索であるため、少しだけ大いに役立つとは思いません。したがって、おそらく他の何かが完全に正しくはありませんが、システムを見ていなかったと推測するのは困難です。