Parece que tiene un plan óptimo para ejecutar la consulta. Va a ser difícil mejorar eso. Aquí hay algunas observaciones.
La consulta está realizando un análisis de índice agrupado en el índice PK_States. No está usando el índice espacial. Esto se debe a que el optimizador de consultas cree que será mejor usar el índice agrupado en lugar de cualquier otro índice. ¿Por qué? Probablemente porque hay pocas filas en la tabla de Estados (50 más quizás algunas otras para Washington, D.C., Puerto Rico, etc.).
SQL Server almacena y recupera datos en páginas de 8 KB. El tamaño de fila (consulte Estimar tamaño de fila) para la operación de filtro es de 8052 bytes, lo que significa que hay una fila por página y alrededor de 50 páginas en toda la tabla. El plan de consulta estima que procesará alrededor de 18 de esas filas (consulte Número estimado de filas). Este no es un número significativo de filas para procesar. Mi explicación no aborda las páginas adicionales que forman parte de la tabla, pero el punto es que el número es de alrededor de 50 y no de 50 000 páginas.
Entonces, volvamos a por qué usa el índice PK_States en lugar del índice SPATIAL_States_Boundry. El índice agrupado, por definición, contiene los datos reales de la tabla. Un índice no agrupado apunta a la página donde se encuentran los datos, por lo que hay más páginas para recuperar. Por lo tanto, el índice no agrupado se vuelve útil solo cuando hay grandes cantidades de datos.
Puede haber cosas que pueda hacer para reducir la cantidad de procesos de páginas (p. ej., usar un índice de cobertura), pero su consulta actual ya está bien optimizada y no verá una gran mejora en el rendimiento.
