Wie kann ich beschleunigen das Sql Server Spatial-Abfrage?

Habe ich (was ich denke) ist eine einfache Sql Server spatial-Abfrage:

Greifen Sie alle USA-Staaten, die gibt es in einem 4-seitiges polygon (ie. der viewport/bounding-box des web-Seite, die die google - /bing-Karte)

SELECT CAST(2 AS TINYINT) AS LocationType, a.Name AS FullName, 
    StateId, a.Name, Boundary.STAsText() AS Boundary, 
    CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a
WHERE @BoundingBox.STIntersects(a.Boundary) = 1

Dauert es 6 Sekunden zu laufen 🙁

Hier ist der Ausführungsplan....

Entfernt

Und die stats auf den Filter-Vorgang...

Entfernt

Nun, ich bin nur nicht sicher, wie Sie Sie Debuggen .., um herauszufinden, was ich brauche, um die Feinabstimmung, etc. Habe ich irgendwelche räumliche Indizes? Ich glaube, so ...

/****** Object:  Index [SPATIAL_States_Boundary]    
        Script Date: 07/28/2010 18:03:17 ******/
CREATE SPATIAL INDEX [SPATIAL_States_Boundary] ON [dbo].[States] 
(
    [Boundary]
)USING  GEOGRAPHY_GRID 
WITH (
    GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), 
    CELLS_PER_OBJECT = 1024, PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, 
    DROP_EXISTING = OFF, ALLOW_ROW_LOCKS  = ON, 
    ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Brauche ich, um etwas mehr Informationen über die GEOGRAPHY Daten, die zurückgegeben wird? zB. Anzahl der Punkte, etc? Oder benötige ich, um profiler und geben Sie einige Statistiken von dort?

Oder sind meine Cells_per_object - /Grids falsch eingestellt ( ich habe wirklich keine Ahnung, was ich werden sollte, diese Werte zu, TBH).

Kann bitte jemand helfen? Bitte?

UPDATE/EDIT:

Nach der ersten Antwort von @Bobs unter, die bestätigt, dass der räumliche index nicht immer verwendet, da der Primary Key (clustered Index) wäre schneller als ein nicht-gruppierter index für eine Tabelle mit 50 ungerade Zeilen ... ich habe dann versucht zu zwingen, den Räumlichen Index (für die hosenscheisser-n-kichert) :-

SELECT CAST(2 AS TINYINT) AS LocationType, a.Name AS FullName, 
    StateId, a.Name, Boundary.STAsText() AS Boundary, 
    CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a WITH (INDEX(SPATIAL_States_Boundary))
WHERE @BoundingBox.STIntersects(a.Boundary) = 1

... und erraten, was .. führt die Abfrage sofort.

WTF??? Alle anderen wissen, warum? Muss ich die post ein Abfrageplan für das, auch, zu helfen, zu erklären, warum/was?

InformationsquelleAutor Pure.Krome | 2010-07-28

7

Es scheint, dass Sie einen optimalen plan für die Ausführung der Abfrage. Es wird hart sein sich zu verbessern. Hier sind einige Beobachtungen.

Die Abfrage ist dabei ein Clustered Index-Scan auf der PK_States index. Es ist nicht mit dem räumlichen index. Dies ist, weil der Abfrageoptimierer denkt, es wird besser sein, verwenden Sie den gruppierten index statt von einem anderen index. Warum? Wahrscheinlich, weil es wenige Zeilen in der Tabelle Status (50 plus vielleicht ein paar andere für Washington, DC, Puerto Rico, etc.).

SQL-Server speichert und ruft Daten über 8 Kb-Seiten. Die Zeile Größe (siehe Schätzung Zeile Größe) für den filter-Vorgang wird 8052 Byte, was bedeutet, es gibt eine Zeile pro Seite und die etwa 50 Seiten in der gesamten Tabelle. Der Abfrage-plan schätzt, dass es circa 18 dieser Zeilen (Siehe die Geschätzte Anzahl von Zeilen). Dieses ist nicht eine bedeutende Anzahl von Zeilen zu verarbeiten. Meine Erklärung geht nicht auf extra-Seiten, die Teil der Tabelle, aber der Punkt ist, dass die Zahl um 50 und nicht 50.000 Seiten.

So, zurück zum Grund, warum es verwendet die PK_States index anstelle der SPATIAL_States_Boundry index. Dem gruppierten index, der definitionsgemäß enthält die eigentlichen Daten der Tabelle. Ein non-clustered-index-Punkte auf der Seite, wo die Daten vorhanden sind, so gibt es mehr Seiten zu Holen. Also, die non-clustered-index wird nur sinnvoll bei größeren Datenmengen.

Möglicherweise gibt es Dinge, die Sie tun können, um reduzieren Sie die Anzahl der Seiten verarbeitet werden (z.B. verwenden Sie einen abdeckenden index), aber die aktuelle Abfrage ist schon gut optimiert, und Sie werden nicht sehen, viel verbessert werden.

Jubel für die ausführliche Antwort. Ich wirklich wirklich wirklich zu schätzen 🙂 Ein paar mehr Fragen : wenn der Abfrageoptimierer entscheidet sich der Gruppierte Index - kewl. Und du hast Recht .. es ist nur um 56 oder so Zeilen in dieser Tabelle. So, warum würde es so lange dauern? gibt es etwas anderes ich kann sehen, wo der Durchsatz der erste Treffer 🙁 Wenn es nicht die Abfrage .. was kann es sein? (der server läuft nicht bei 100%, btw).
ich habe auch aktualisiert die erste post mit ein paar mehr Infos .. nach unten unter EDIT/UPDATE. Kannst du bitte noch ein re-read?
Das ist sehr interessant, dass der räumliche index so gut funktioniert. Ich vermute, dass die Leistung zu bewerten, die räumliche Bedingung, die den gruppierten index ist nicht so schnell wie mit dem räumlichen index. Zu Testzwecken könnten Sie versuchen, einen nicht-gruppierten index auf eine nicht-räumliche Spalte und ausführen einer Abfrage, verwendet diese Spalte. Dann sehen Sie, wie die Abfrage im Vergleich zu Ihrer vorherigen Abfragen. Es wäre interessant zu sehen, wie eine Abfrage ohne räumliche Logik führt.

InformationsquelleAutor bobs
2

Versuchen, diese, w/out der index-Hinweis:
```
EXEC sp_executesql N'
  SELECT CAST(2 AS TINYINT) AS LocationType, a.Name AS FullName, 
      StateId, a.Name, Boundary.STAsText() AS Boundary, 
      CentrePoint.STAsText() AS CentrePoint
  FROM [dbo].[States] a
  WHERE @BoundingBox.STIntersects(a.Boundary) = 1'
, N'@BoundingBox GEOGRAPHY', @BoundingBox
```
Wenn das macht keinen Unterschied, siehe hier weitere details:

Wenn Sie den code in SSMS,
verwenden von sp_executesql um die räumliche
Abfrage (oder verwenden Sie Ihre eigenen gespeicherten
Verfahren mit dem Geo-Wert als ein
parameter), um sicherzustellen, die Abfrage coster
"kennt" den parameter-Wert an der
Zeit seiner Erstellung der Abfrage-plan, dass
ist, am Anfang der batch-oder auf
Eintrag eine gespeicherte Prozedur oder
sp_executesql.

interessant ... Also zog ich ihn in eine gespeicherte Prozedur, mit der boundingBox variable immer übergeben. Es ist jetzt 9 Sekunden, mit no INDEX gewöhnungsbedürftig. Dies ist auf SQL 2008 R2 / 10.50 RTM.
außerdem läuft es (wie oben) in SSMS gibt in 9 Sekunden, mit no Index gewöhnungsbedürftig und putting obigen code in eine gespeicherte Prozedur mit der BoundingBox variable immer übergeben, macht das gleiche wieder. 🙁
Das ist ziemlich lustig. Sie könnte auch spielen, um w -./ .Filter(), wenn Sie nicht bereits getan haben. Ich finde mich oft materialisieren die Ergebnisse .Filter() in eine temp-Tabelle, und dann mehr tun, präzise Operationen aus.
Außerdem empfehle ich cross-posting in social.msdn.microsoft.com/Forums/en-US/sqlspatial. Die Leserschaft, es ist viel besser, als SO zu für SQL Server spatial-Fragen.

InformationsquelleAutor Peter Radocchia

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.