Het lijkt erop dat u een optimaal plan heeft om de query uit te voeren. Het zal moeilijk worden om dat te verbeteren. Hier zijn enkele observaties.
De query voert een geclusterde indexscan uit op de PK_States-index. Het gebruikt de ruimtelijke index niet. Dit komt omdat de query-optimizer denkt dat het beter is om de geclusterde index te gebruiken in plaats van een andere index. Waarom? Waarschijnlijk omdat er weinig rijen zijn in de tabel Staten (50 plus misschien een paar andere voor Washington, D.C., Puerto Rico, enz.).
SQL Server slaat gegevens op en haalt deze op op pagina's van 8 KB. De rijgrootte (zie Rijgrootte schatten) voor de filterbewerking is 8052 bytes, wat betekent dat er één rij per pagina is en ongeveer 50 pagina's in de hele tabel. Het queryplan schat dat het ongeveer 18 van die rijen zal verwerken (zie geschat aantal rijen). Dit is niet een significant aantal rijen om te verwerken. Mijn uitleg gaat niet over extra pagina's die deel uitmaken van de tabel, maar het punt is dat het aantal rond de 50 ligt en niet 50.000 pagina's.
Dus, terug naar waarom het de PK_States-index gebruikt in plaats van de SPATIAL_States_Boundry-index. De geclusterde index bevat per definitie de feitelijke gegevens voor de tabel. Een niet-geclusterde index verwijst naar de pagina waar de gegevens staan, dus er zijn meer pagina's om op te halen. De niet-geclusterde index wordt dus alleen nuttig als er grotere hoeveelheden gegevens zijn.
Er zijn misschien dingen die u kunt doen om het aantal pagina's te verminderen (bijvoorbeeld een dekkende index gebruiken), maar uw huidige zoekopdracht is al goed geoptimaliseerd en u zult niet veel prestatieverbetering zien.