Verwenden Sie die SVL _ QUERY _ SUMMARY -Ansicht - Amazon Redshift

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie die SVL _ QUERY _ SUMMARY -Ansicht

Gehen Sie wie folgt vorSVL_QUERY_SUMMARY, um die zusammenfassenden Abfrageinformationen nach Stream zu analysieren:

  1. Führen Sie die folgende Abfrage aus, um die Abfrage-ID anzuzeigen:

    select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;

    Untersuchen Sie den Abfrageausschnitt im Feld substring, um herauszufinden, welcher query-Wert Ihrer Abfrage entspricht. Wenn Sie die Abfrage mehrmals ausgeführt haben, verwenden Sie den query-Wert aus der Zeile mit dem niedrigeren elapsed-Wert. Dies ist die Zeile für die kompilierte Version. Wenn Sie viele Abfragen ausgeführt haben, können Sie den Wert erhöhen, der in der verwendeten LIMIT Klausel verwendet wird, um sicherzustellen, dass Ihre Abfrage enthalten ist.

  2. Wählen Sie Zeilen aus SVL _ QUERY _ SUMMARY für Ihre Abfrage aus. Ordnen Sie die Ergebnisse nach Stream, Segment und Schritt an:

    select * from svl_query_summary where query = MyQueryID order by stm, seg, step;

    Nachfolgend sehen Sie ein Beispielergebnis.

    Ein Beispielergebnis für Zeilen in SVL _ QUERY _, SUMMARY die einer bestimmten Abfrage entsprechen.

  3. Ordnen Sie die Schritte und die Operationen in dem Abfrageplan einander zu. Verwenden Sie dabei die Informationen in Zuweisung der Informationen in Abfrageplan und Abfragezusammenfassung. Zusammengehörige Elemente sollten näherungsweise die gleichen Werte für Zeilen und Bytes (jeweils Zeilen * Breite aus dem Abfrageplan) haben. Falls sich hier unerwartete Abweichungen ergeben, finden Sie empfohlene Lösungen unter Die Tabellenstatistik fehlt oder ist veraltet..

  4. Überprüfen Sie, ob das Feld is_diskbased für einen Schritt den Wert t (true) hat. Hashes, Aggregat- und Sortierfunktionen sind Operatoren, die mit hoher Wahrscheinlichkeit Daten auf den Datenträger schreiben, falls das System nicht genügend Arbeitsspeicher für die Verarbeitung der Abfrage zugeteilt hat.

    Falls is_diskbased wahr ist, finden Sie empfohlene Lösungen unter Ungenügende Speicherzuteilung für die Abfrage.

  5. Überprüfen Sie die label Feldwerte und prüfen Sie, ob es irgendwo in den Schritten eine AGG-DIST-AGG Reihenfolge gibt. Eine solche Konstellation weist auf eine Aggregierung in zwei Schritten hin, die kostenintensiv ist. Um dieses Problem zu beheben, ändern Sie die GROUP BY-Klausel so, dass sie den Verteilungsschlüssel verwendet (den ersten Schlüssel, falls es mehrere gibt).

  6. Überprüfen Sie für jedes Segment den Wert von maxtime (ist für alle Schritte in einem Segment gleich). Identifizieren Sie das Segment mit dem höchsten maxtime-Wert und durchsuchen Sie die Schritte in diesem Segment nach den folgenden Operatoren.

    Anmerkung

    Ein hoher maxtime-Wert muss nicht zwangsläufig ein Problem bei dem Segment bedeuten. Auch Segmente, bei denen dieser Wert hoch ist, können schnell verarbeitet worden sein. Die Zeitmessung wird für alle Segmente in einem Stream gleichzeitig gestartet. Einige nachgelagerte Segmente können aber erst dann ausgeführt werden, wenn Daten aus vorangehenden Segmenten abrufbar sind. Dies führt dazu, dass offenbar viel Zeit benötigt wird, weil der maxtime-Wert die Warte- und die Verarbeitungszeit beinhaltet.

    • BCASToder DIST: In diesen Fällen kann der hohe maxtime Wert das Ergebnis einer Neuverteilung einer großen Anzahl von Zeilen sein. Empfohlene Lösungen finden Sie unter Suboptimale Datenverteilung.

    • HJOIN(Hash-Join): Wenn der fragliche Schritt im rows Feld einen sehr hohen Wert im Vergleich zu dem rows Wert im letzten RETURN Schritt der Abfrage aufweist, finden Sie unter Hash join Lösungsvorschläge.

    • SCAN/SORT: Suchen Sie nach einer SCANSORT,SCAN, MERGE Schrittfolge kurz vor einem Join-Schritt. Ein solches Muster weist darauf hin, dass unsortierte Daten gescannt, sortiert und dann mit dem sortierten Bereich der Tabelle zusammengeführt werden.

      Prüfen Sie, ob der Zeilenwert für den SCAN Schritt im Vergleich zum Zeilenwert im letzten RETURN Schritt der Abfrage einen sehr hohen Wert hat. Ein solches Muster weist darauf hin, dass die Ausführungs-Engine Zeilen scannt, die später verworfen werden, was ineffizient ist. Empfohlene Lösungen finden Sie unter Nicht ausreichend restriktives Prädikat.

      Wenn der maxtime Wert für den SCAN Schritt hoch ist, finden Sie Suboptimale Klausel WHERE Lösungsvorschläge unter.

      Wenn der rows Wert für den SORT Schritt nicht Null ist, finden Sie Unsortierte oder falsch sortierte Zeilen Lösungsvorschläge unter.

  7. Sehen Sie sich die bytes Werte rows und für die 5—10 Schritte an, die dem letzten RETURN Schritt vorausgehen, um sich ein Bild von der Datenmenge zu machen, die an den Client zurückgegeben wird. Dies ist nicht immer ganz einfach.

    In der folgenden Beispielabfragezusammenfassung liefert der dritte PROJECT Schritt beispielsweise einen rows Wert, aber keinen Wert. bytes Wenn Sie die vorherigen Schritte nach einem Schritt mit demselben rows Wert durchsuchen, finden Sie den SCAN Schritt, der sowohl Zeilen- als auch Byteinformationen bereitstellt.

    Im Folgenden sehen Sie ein Beispielergebnis.

    Eine Zeile in den Ergebnissen der Abfragezusammenfassung, bei der es sich um einen SCAN Schritt handelt, der sowohl Zeilen- als auch Byteinformationen enthält.

    Wenn die zurückgegebene Datenmenge unerwartet groß ist, finden Sie empfohlene Lösungen unter Sehr große Ergebnismengen.

  8. Überprüfen Sie, ob der Wert für bytes verglichen mit den rows-Werten für andere Schritte relativ hoch ist. Dieses Muster kann darauf hinweisen, dass eine große Anzahl an Spalten ausgewählt ist. Empfohlene Lösungen finden Sie unter Große SELECT Liste.