Frage

Ich habe derzeit eine Site mit einer Tabelle mit Lat/Long-Float-Spalten und einem Index über diese beiden Spalten sowie einer weiteren, die ich abrufen muss.

Ich frage diese Tabelle ständig ab, um die Zeilen zu erhalten, die von einem bestimmten Punkt aus in einen Radius fallen (eigentlich erhalte ich ein Quadrat für die Geschwindigkeit), aber ich benötige nur die Felder, die bereits indiziert sind, sodass dieser Index tatsächlich abdeckt , und der Ausführungsplan besteht nur aus 2 Schritten:

Index Seek  (cost: 100%) and SELECT (cost: 0%)

Jetzt versuche ich, die räumlichen Funktionen von SQL 2008 zu nutzen.Ich habe die Spalte „Geographie“ erstellt, sie gefüllt, den räumlichen Index erstellt, die Arbeiten.

Und alles funktioniert gut, außer dass der Ausführungsplan eine Million Schritte umfasst und 74 % der Zeit für eine Clustered-Index-Suche aufgewendet wird, bei der die im räumlichen Index gefundenen Zeilen mit der tatsächlichen Tabelle verknüpft werden, um den Rest zu erhalten der Daten...
(Die räumliche Indexsuche kostet 1 % der Ausführungsplankosten)

Anscheinend nutzt es also den Spatial-Index richtig und findet die Datensätze, die ich benötige, viel schneller als zuvor mit meinem „normalen“ Index über Lat/Long, aber die Verknüpfung mit der Haupttabelle bringt mich um, die Spatial-Abfrage dauert siebenmal so lange so lang wie mein altes.

Gibt es eine Möglichkeit, dem räumlichen Index weitere Spalten hinzuzufügen, damit er ihn abdeckt und Dinge in einem Schritt erledigen kann, genau wie zuvor?
Gibt es andere Dinge, die ich tun könnte, um diese Situation zu verbessern?


AKTUALISIEREN:Ich habe herausgefunden, dass „normale“ Indizes andere Spalten mit dem Schlüsselwort INCLUDE „einschließen“ können (was ich nicht wusste, ich habe die Spalten früher einfach in den Index selbst aufgenommen).
Laut Dokumentation Hier, diese Klausel ist keine Option für räumliche Indizes ...Irgendwelche Ideen?

Danke!
Daniel

War es hilfreich?

Lösung

Nein, leider gibt es derzeit keine Möglichkeit, einen umfassenden räumlichen Index zu erstellen – die Abfrage führt immer die Lesezeichensuche in der Basistabelle durch, um den geografischen Wert für die Zeile zu erhalten.

Für STIntersects ist dies eindeutig immer erforderlich, da wir immer noch den sekundären Filter für das tatsächliche Geografieobjekt durchführen müssen, um zu überprüfen, ob es tatsächlich das Parameterobjekt schneidet.Wenn Sie jedoch keine genauen Antworten benötigen und Filter() verwenden können, wäre es möglich, die Primärschlüsselspalten aus dem Index bereitzustellen, ohne überhaupt in der Basistabelle nachzuschlagen.Wir denken darüber nach, dies für die nächste Version zu unterstützen.

Haben Sie im Hinblick auf die Beschleunigung Ihrer aktuellen Abfrage versucht, Filter() zu verwenden und Ihren Index mit der Ausgabe von sp_help_geography_index zu optimieren?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top