Det verkar som att du har en optimal plan för att köra frågan. Det kommer att bli svårt att förbättra det. Här är några observationer.
Frågan gör en Clustered Index Scan på PK_States-indexet. Det använder inte det rumsliga indexet. Detta beror på att frågeoptimeraren tror att det kommer att vara bättre att använda det klustrade indexet istället för vilket annat index som helst. Varför? Förmodligen för att det finns få rader i tabellen för stater (50 plus kanske några andra för Washington, D.C., Puerto Rico, etc.).
SQL Server lagrar och hämtar data på 8KB-sidor. Radstorleken (se Uppskatta radstorlek) för filteroperationen är 8052 byte, vilket innebär att det finns en rad per sida och cirka 50 sidor i hela tabellen. Frågeplanen uppskattar att den kommer att bearbeta cirka 18 av dessa rader (se uppskattat antal rader). Detta är inte ett betydande antal rader att bearbeta. Min förklaring tar inte upp extra sidor som ingår i tabellen, men poängen är att antalet är runt 50 och inte 50 000 sidor.
Så, tillbaka till varför den använder PK_States-indexet istället för SPATIAL_States_Boundry-indexet. Det klustrade indexet innehåller per definition de faktiska data för tabellen. Ett icke-klustrat index pekar på sidan där data finns, så det finns fler sidor att hämta. Så det icke-klustrade indexet blir användbart endast när det finns större mängder data.
Det kan finnas saker du kan göra för att minska antalet sidprocesser (t.ex. använda ett täckande index), men din nuvarande fråga är redan väl optimerad och du kommer inte att se mycket prestandaförbättringar.