Il semble que vous disposiez d'un plan optimal pour exécuter la requête. Ça va être dur de s'améliorer là-dessus. Voici quelques observations.
La requête effectue une analyse d'index clusterisée sur l'index PK_States. Il n'utilise pas l'index spatial. En effet, l'optimiseur de requête pense qu'il est préférable d'utiliser l'index clusterisé au lieu de tout autre index. Pourquoi? Probablement parce qu'il y a peu de lignes dans la table des États (50 plus peut-être quelques autres pour Washington, D.C., Porto Rico, etc.).
SQL Server stocke et récupère les données sur des pages de 8 Ko. La taille de ligne (voir Estimation de la taille de ligne) pour l'opération de filtrage est de 8052 octets, ce qui signifie qu'il y a une ligne par page et environ 50 pages dans l'ensemble du tableau. Le plan de requête estime qu'il traitera environ 18 de ces lignes (voir Nombre de lignes estimé). Ce n'est pas un nombre significatif de lignes à traiter. Mon explication ne concerne pas les pages supplémentaires qui font partie du tableau, mais le fait est que le nombre est d'environ 50 et non 50 000 pages.
Revenons donc à la raison pour laquelle il utilise l'index PK_States au lieu de l'index SPATIAL_States_Boundry. L'index clusterisé, par définition, contient les données réelles de la table. Un index non clusterisé pointe vers la page où les données existent, il y a donc plus de pages à récupérer. Ainsi, l'index non clusterisé devient utile uniquement lorsqu'il y a de plus grandes quantités de données.
Il peut y avoir des choses que vous pouvez faire pour réduire le nombre de processus de pages (par exemple, utiliser un index de couverture), mais votre requête actuelle est déjà bien optimisée et vous ne verrez pas beaucoup d'amélioration des performances.
