クエリを実行するための最適な計画があるようです。そこを改善するのは難しいでしょう。ここにいくつかの観察があります。
クエリは、PK_States インデックスでクラスター化インデックス スキャンを実行しています。空間インデックスを使用していません。これは、クエリ オプティマイザーが、他のインデックスではなくクラスター化インデックスを使用する方が適切であると判断したためです。なんで？おそらく、States テーブルに行がほとんどないためです (50 に加えて、ワシントン D.C.、プエルトリコなどの他の行がいくつかある可能性があります)。
SQL Server は、8KB ページでデータを格納および取得します。フィルター操作の行サイズ (「行サイズの見積もり」を参照) は 8052 バイトです。これは、1 ページあたり 1 行、テーブル全体で約 50 ページであることを意味します。クエリ プランは、それらの行のうち約 18 行を処理すると見積もっています (「見積行数」を参照)。これは、処理する重要な行数ではありません。私の説明では、テーブルの一部である余分なページについては触れていませんが、要点は、その数が 50,000 ページではなく約 50 であるということです。
SPATIAL_States_Boundry インデックスの代わりに PK_States インデックスを使用する理由に戻ります。クラスタ化インデックスには、定義上、テーブルの実際のデータが含まれています。非クラスター化インデックスは、データが存在するページを指しているため、取得するページがさらにあります。したがって、非クラスター化インデックスは、大量のデータがある場合にのみ役立ちます。
ページ プロセスの数を減らすためにできることはあるかもしれませんが (たとえば、カバリング インデックスを使用する)、現在のクエリは既に十分に最適化されており、パフォーマンスの大幅な向上は見られません。