Det ser ud til, at du har en optimal plan for at køre forespørgslen. Det bliver svært at forbedre det. Her er nogle observationer.
Forespørgslen udfører en Clustered Index Scan på PK_States-indekset. Det bruger ikke det rumlige indeks. Dette skyldes, at forespørgselsoptimeringsværktøjet mener, at det vil være bedre at bruge det klyngede indeks i stedet for et hvilket som helst andet indeks. Hvorfor? Sandsynligvis fordi der er få rækker i staternes tabel (50 plus måske et par andre for Washington, D.C., Puerto Rico osv.).
SQL Server gemmer og henter data på 8KB sider. Rækkestørrelsen (se Estimer rækkestørrelse) for filteroperationen er 8052 bytes, hvilket betyder, at der er en række pr. side og omkring 50 sider i hele tabellen. Forespørgselsplanen anslår, at den vil behandle omkring 18 af disse rækker (se estimeret antal rækker). Dette er ikke et betydeligt antal rækker, der skal behandles. Min forklaring omhandler ikke ekstra sider, der er en del af tabellen, men pointen er, at tallet er omkring 50 og ikke 50.000 sider.
Så tilbage til hvorfor den bruger PK_States-indekset i stedet for SPATIAL_States_Boundry-indekset. Det klyngede indeks indeholder pr. definition de faktiske data for tabellen. Et ikke-klynget indeks peger på den side, hvor dataene findes, så der er flere sider at hente. Så det ikke-klyngede indeks bliver kun nyttigt, når der er større mængder data.
Der kan være ting, du kan gøre for at reducere antallet af siders processer (f.eks. bruge et dækkende indeks), men din nuværende forespørgsel er allerede godt optimeret, og du vil ikke se meget forbedring af ydeevnen.