Verbessern der Abfrageleistung

Nachstehend finden Sie eine Liste häufig auftretender Probleme, die die Abfrageleistung beeinträchtigen, und Möglichkeiten zu ihrer Diagnose und Behandlung.

Die Tabellenstatistik fehlt oder ist veraltet.

Wenn die Statistik für die Tabellen nicht vorhanden oder veraltet sind, sieht die Ausgabe wie folgt aus:

• In den Ergebnissen für EXPLAIN eine Warnmeldung.

• In STL_ALERT_EVENT_LOG ein Warnereignis zu fehlender Statistik. Weitere Informationen finden Sie unter Überprüfen von Abfragewarnungen.

Führen Sie den Befehl aus, um dieses Problem zu beheben ANALYZE.

Verschachtelte Schleife

Wenn eine verschachtelte Schleife vorhanden ist, wird häufig ein entsprechendes Warnereignis in STL_ALERT_EVENT_LOG protokolliert. Sie können diese Art von Ereignissen auch identifizieren, indem Sie die Abfrage unter Identifizieren von Abfragen mit verschachtelten Schleifen. Weitere Informationen finden Sie unter Überprüfen von Abfragewarnungen.

Um diesem Verhalten entgegenzuwirken, überprüfen Sie Ihre Abfragen auf Kreuz-Joins und entfernen Sie sie nach Möglichkeit. Kreuz-Joins haben keine Join-Bedingung, daher ist das Ergebnis das kartesische Produkt zweier Tabellen. Sie werden typischerweise als verschachtelte Loop-Joins ausgeführt; dies ist die langsamste der Join-Varianten.

Hash join

Wenn ein Hash-Join vorhanden ist, sieht die Ausgabe wie folgt aus:

• Hash- und Hash-Join-Operationen im Abfrageplan. Weitere Informationen finden Sie unter Analysieren des Abfrageplans.

• Ein HJOIN-Schritt in dem Segment mit dem höchsten Wert für „maxtime“ in SVL_QUERY_SUMMARY. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Um dieses Problem zu beheben, sind eine Reihe von Ansätzen möglich:

• Formulieren Sie die Abfrage nach Möglichkeit so um, dass ein Zusammenführungs-Join verwendet wird. Sie können dies erreichen, indem Sie Spalten für die Join-Operationen angeben, die gleichzeitig Verteilungsschlüssel und Sortierschlüssel sind.

• Wenn der HJOIN-Schritt in SVL_QUERY_SUMMARY im Vergleich zu dem Wert im Feld „rows“ im abschließenden RETURN-Schritt in der Abfrage einen sehr großen Wert aufweist, überprüfen Sie, ob Sie die Abfrage nicht so formulieren können, dass die Join-Operation über eine einzige Spalte durchgeführt werden kann. Wenn eine Abfrage eine Join-Operation über eine Spalte durchführt, die nicht eindeutig (also beispielsweise kein Primärschlüssel) ist, bedeutet dies, dass bei der Operation mehr Zeilen verarbeitet werden müssen.

Geisterzeilen und Zeilen mit ausstehendem Commit

Wenn es Geisterzeilen oder Zeilen mit ausstehendem Commit gibt, wird möglicherweise ein Warnereignis in STL_ALERT_EVENT_LOG protokolliert, das auf eine große Anzahl von Geisterzeilen hinweist. Weitere Informationen finden Sie unter Überprüfen von Abfragewarnungen.

Um dieses Problem zu beheben, sind eine Reihe von Ansätzen möglich:

• Überprüfen Sie die Registerkarte Loads (Ladevorgänge) Ihrer Amazon-Redshift-Konsole auf aktive Ladevorgänge für eine der Abfragetabellen. Wenn dies der Fall ist, warten Sie, bis diese Operationen abgeschlossen sind, bevor Sie weitere Schritte unternehmen.

• Falls keine Ladeoperationen aktiv sind, führen Sie über den Tabellen der Abfrage den Befehl VACUUM aus, um gelöschte Zeilen ganz aus dem Speicher zu löschen.

Unsortierte oder falsch sortierte Zeilen

Wenn unsortierte oder falsch sortierte Zeilen vorhanden sind, wird häufig ein Warnereignis mit starker Beschränkung in STL_ALERT_EVENT_LOG protokolliert. Weitere Informationen finden Sie unter Überprüfen von Abfragewarnungen.

Sie können auch überprüfen, ob in einer der Tabellen in Ihrer Abfrage große unsortierte Bereiche vorhanden sind, indem Sie die Abfrage in ausführen Identifizieren von Tabellen mit verzerrter Datenverteilung oder unsortierten Zeilen.

Um dieses Problem zu beheben, sind eine Reihe von Ansätzen möglich:

• Führen Sie den Befehl VACUUM über den Tabellen der Abfrage aus, um die Zeilen zu sortieren.

• Überprüfen Sie, ob Verbesserungen an den Sortierschlüsseln der Tabellen in der Abfrage möglich sind. Achten Sie dabei darauf, zwischen der Leistung dieser Abfrage und der von anderen wichtigen Abfragen und der gesamten Systemleistung, falls Sie Modifikationen vornehmen möchten. Weitere Informationen finden Sie unter Arbeiten mit Sortierschlüsseln.

Suboptimale Datenverteilung

Wenn die Datenverteilung suboptimale ist, sieht die Ausgabe wie folgt aus:

• Es wird ein Warnereignis zur reihenweisen Ausführung, zu umfangreichen Broadcastoperationen oder zu umfangreichen Verteilungen in STL_ALERT_EVENT_LOG protokolliert. Weitere Informationen finden Sie unter Überprüfen von Abfragewarnungen.

• In einem Schritt verarbeiten bestimmte Slices bedeutend mehr Zeilen als die anderen. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_REPORT.

• In einem Schritt dauert die Verarbeitung bei bestimmten Slices bedeutend länger als bei den anderen. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_REPORT.

Wenn keine der vorangehenden Bedingungen zutrifft, können Sie auch überprüfen, ob in einer der Tabellen in Ihrer Abfrage die Datenverteilung verzerrt ist, indem Sie die Abfrage in ausführen Identifizieren von Tabellen mit verzerrter Datenverteilung oder unsortierten Zeilen.

In diesem Fall können Sie versuchen, das Problem zu beheben, indem Sie sich die Verteilungsstile für die Tabellen in der Abfrage ansehen und prüfen, ob Verbesserungen vorgenommen werden können. Achten Sie dabei darauf, zwischen der Leistung dieser Abfrage und der von anderen wichtigen Abfragen und der gesamten Systemleistung, falls Sie Modifikationen vornehmen möchten. Weitere Informationen finden Sie unter Arbeiten mit Datenverteilungsstilen.

Ungenügende Speicherzuteilung für die Abfrage

Wenn Ihrer Abfrage nicht genügend Arbeitsspeicher zugeteilt ist, sehen Sie möglicherweise, dass für einen Schritt in SVL_QUERY_SUMMARY der Wert für is_diskbased auf „true“ gesetzt ist. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Sie können in diesem Fall das Problem beheben, indem Sie der Abfrage mehr Speicherplatz zuteilen, indem Sie die Anzahl der für die Abfrage verwendeten Abfrageplätze vorübergehend erhöhen. Workload Management (WLM) reserviert die Plätze in einer Abfragewarteschlange entsprechend der für die Warteschlange festgelegten Parallelausführungsstufe (Gleichzeitigkeitsstufe). Ein Beispiel: Eine Warteschlange mit einer Gleichzeitigkeitsstufe von 5 hat 5 Plätze. Der der Warteschlange zugewiesene Arbeitsspeicher wird gleichmäßig auf die Plätze verteilt. Wenn Sie einer Abfrage mehrere Plätze zuweisen, erhält die Abfrage den Arbeitsspeicher für alle Plätze, die ihr zugewiesen sind. Weitere Informationen dazu, wie Sie einer Abfrage vorübergehenden mehr Warteschlangenplätze zuweisen, Sie unter wlm_query_slot_count.

Suboptimale WHERE-Klausel

Wenn eine WHERE-Klausel dazu führt, dass umfangreiche Tabellenscans durchgeführt werden müssen, gibt es möglicherweise in SVL_QUERY_SUMMARY einen SCAN-Schritt in dem Segment mit dem größten maxtime-Wert. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Sie können dieses Problem beheben, indem Sie der Abfrage eine WHERE-Klausel auf der Grundlage der primären Sortierspalte der größten Tabelle hinzufügen. Dieser Ansatz hilft Ihnen, die für das Scannen der Tabellen benötigte Zeit zu minimieren. Weitere Informationen finden Sie unter Bewährte Methoden für die Gestaltung von Tabellen mit Amazon Redshift.

Nicht ausreichend restriktives Prädikat

Wenn das in der Abfrage verwendete Prädikat nicht ausreichend restriktiv ist, wird möglicherweise in SVL_QUERY_SUMMARY in dem Segment mit dem höchsten maxtime-Wert ein SCAN-Schritt angezeigt, der im Feld rows im Vergleich zu dem Wert im Feld rows im abschließenden RETURN-Schritt in der Abfrage einen sehr großen Wert aufweist. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Sie können versuchen, dieses Problem zu beheben, indem Sie der Abfrage ein Prädikat hinzufügen oder indem Sie ein vorhandenes Prädikat restriktiver formulieren, um die Ausgabe einzuschränken.

Sehr große Ergebnismengen

Wenn Ihre Abfrage einen sehr großen Ergebnissatz zurückgibt, sollten Sie die Abfrage neu schreiben und UNLOAD verwenden, um die Ergebnisse zu Amazon S3 schreiben. Dieser Ansatz verbessert die Leistung des RETURN-Schritts durch Ausnutzung der Parallelverarbeitung. Weitere Informationen zum Überprüfen, ob sehr große Ergebnismengen zurückgegeben werden, finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Große SELECT-Liste

Wenn Ihre Abfrage eine ungewöhnlich große SELECT-Liste erzeugt, wird dies in SVL_QUERY_SUMMARY möglicherweise dadurch ersichtlich, dass in einem bestimmten Schritt der bytes-Wert für einen Schritt im Vergleich zu dem rows-Wert ungewöhnlich groß ist. Der große Wert für bytes kann darauf hinweisen, dass eine große Anzahl an Spalten ausgewählt ist. Weitere Informationen finden Sie unter Verwenden der Ansicht SVL_QUERY_SUMMARY.

Um dieses Problem zu beheben, überprüfen Sie die bei der Abfrage ausgewählten Spalten daraufhin, ob sie aus der Abfrage entfernt werden können.