Anscheinend haben Sie einen optimalen Plan zum Ausführen der Abfrage. Es wird schwierig, das zu verbessern. Hier sind einige Beobachtungen.
Die Abfrage führt einen Clustered Index Scan für den PK_States-Index durch. Es verwendet nicht den räumlichen Index. Dies liegt daran, dass der Abfrageoptimierer der Meinung ist, dass es besser ist, den gruppierten Index anstelle eines anderen Index zu verwenden. Wieso den? Wahrscheinlich, weil die Tabelle „Staaten“ nur wenige Zeilen enthält (50 plus vielleicht ein paar andere für Washington, D.C., Puerto Rico usw.).
SQL Server speichert und ruft Daten auf 8-KB-Seiten ab. Die Zeilengröße (siehe Zeilengröße schätzen) für die Filteroperation beträgt 8052 Bytes, was bedeutet, dass es eine Zeile pro Seite und etwa 50 Seiten in der gesamten Tabelle gibt. Der Abfrageplan schätzt, dass etwa 18 dieser Zeilen verarbeitet werden (siehe Geschätzte Anzahl von Zeilen). Dies ist keine signifikante Anzahl von zu verarbeitenden Zeilen. Meine Erklärung bezieht sich nicht auf zusätzliche Seiten, die Teil der Tabelle sind, aber der Punkt ist, dass die Zahl bei etwa 50 und nicht bei 50.000 Seiten liegt.
Also zurück zu dem Grund, warum es den PK_States-Index anstelle des SPATIAL_States_Boundry-Index verwendet. Der gruppierte Index enthält per Definition die eigentlichen Daten für die Tabelle. Ein nicht gruppierter Index zeigt auf die Seite, auf der die Daten vorhanden sind, sodass mehr Seiten abzurufen sind. Der Non-Clustered-Index wird also nur dann sinnvoll, wenn größere Datenmengen vorhanden sind.
Möglicherweise können Sie die Anzahl der Seitenprozesse reduzieren (z. B. einen abdeckenden Index verwenden), aber Ihre aktuelle Abfrage ist bereits gut optimiert und Sie werden keine große Leistungsverbesserung feststellen.
