Sembra che tu abbia un piano ottimale per eseguire la query. Sarà difficile migliorare su questo. Ecco alcune osservazioni.
La query sta eseguendo una scansione dell'indice cluster sull'indice PK_States. Non sta usando l'indice spaziale. Questo perché Query Optimizer pensa che sarà meglio usare l'indice cluster invece di qualsiasi altro indice. Come mai? Probabilmente perché ci sono poche righe nella tabella degli Stati (50 più forse poche altre per Washington, D.C., Porto Rico, ecc.).
SQL Server archivia e recupera i dati su pagine da 8 KB. La dimensione della riga (vedi Stima della dimensione della riga) per l'operazione di filtro è 8052 byte, il che significa che c'è una riga per pagina e circa 50 pagine nell'intera tabella. Il piano di query stima che elaborerà circa 18 di tali righe (vedere Numero stimato di righe). Questo non è un numero significativo di righe da elaborare. La mia spiegazione non riguarda le pagine extra che fanno parte della tabella, ma il punto è che il numero è di circa 50 e non 50.000 pagine.
Quindi, torniamo al motivo per cui utilizza l'indice PK_States invece dell'indice SPATIAL_States_Boundry. L'indice cluster, per definizione, contiene i dati effettivi per la tabella. Un indice non cluster punta alla pagina in cui sono presenti i dati, quindi ci sono più pagine da recuperare. Pertanto, l'indice non cluster diventa utile solo quando sono presenti quantità maggiori di dati.
Potrebbero esserci delle cose che puoi fare per ridurre il numero di processi delle pagine (ad esempio, utilizzare un indice di copertura), ma la tua query attuale è già ben ottimizzata e non vedrai molti miglioramenti delle prestazioni.
