Überprüfen von Abfragewarnungen - 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.

Überprüfen von Abfragewarnungen

Verwenden Sie die Systemtabelle STL_ALERT_EVENT_LOG wie folgt, um mögliche Performanceprobleme bei Ihrer Abfrage zu identifizieren und zu korrigieren.

  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, welchen query-Wert Sie auswählen müssen. 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 STL _ ALERT _ EVENT _ LOG für Ihre Abfrage aus:

    Select * from stl_alert_event_log where query = MyQueryID;
    Ein Beispiel für ein Abfrageergebnis von STL ALERT _ EVENT _ _LOG.

  3. Werten Sie die Ergebnisse für Ihre Abfrage aus. Verwenden Sie die folgende Tabelle, um mögliche Lösungen für die identifizierten Probleme zu finden.

    Anmerkung

    Nicht alle Abfragen haben Zeilen in STL _ _ ALERT EVENT _LOG, sondern nur solche mit identifizierten Problemen.

    Problem Ereigniswert Lösungswert Empfohlene Lösung
    Die Statistiken für die Tabellen in der Abfrage sind nicht vorhanden oder veraltet. Statistiken des Abfrageplaners fehlen. Führen Sie den ANALYZE Befehl aus Siehe Die Tabellenstatistik fehlt oder ist veraltet..
    In dem Abfrageplan wird eine verschachtelter Schleifen-Join (die am wenigsten effiziente Join-Variante) angezeigt. Verschachtelter Schleifen-Join in der Abfrage Überprüfen Sie, ob die Join-Prädikate so umformuliert werden können, dass kartesische Produkte vermieden werden. Siehe Verschachtelte Schleife.
    Der Scan hat eine sehr große Anzahl an Zeilen übersprungen, die als gelöscht markiert sind, jedoch noch nicht bereinigt wurden, oder es wurden Zeilen eingefügt, aber nicht per Commit bestätigt. Es wurde eine große Menge an gelöschten Zeilen gescannt. Führen Sie den VACUUM Befehl aus, um gelöschten Speicherplatz zurückzugewinnen Siehe Geisterzeilen und Zeilen mit ausstehendem Commit.
    Für einen Hash-Join oder eine Aggregierung wurden mehr als 1.000.000 Zeilen umverteilt. Eine große Anzahl von Zeilen im Netzwerk verteilt: Die RowCount Zeilen wurden verteilt, um die Aggregation zu verarbeiten Überprüfen Sie die Auswahl des Verteilungsschlüssels, mit dem die Join- oder Aggregat-Operation zusammengefasst werden. Siehe Suboptimale Datenverteilung.
    Für einen Hash-Join wurden mehr als 1.000.000 Zeilen rundgesendet. Es wurden sehr viele Zeilen über das Netzwerk gesendet. Überprüfen Sie die Auswahl des Verteilungsschlüssels, mit dem die Join-Operation zusammengefasst wird, oder verwenden Sie verteilte Tabellen. Siehe Suboptimale Datenverteilung.
    Im Abfrageplan wurde ein DIST ALL DS_ _ _ INNER -Umverteilungsstil angegeben, der eine serielle Ausführung erzwingt, da die gesamte innere Tabelle auf einen einzelnen Knoten umverteilt wurde. DS_ _ DIST ALL _ INNER für Hash Join im Abfrageplan Überprüfen Sie die Auswahl des Verteilungsschlüssels, um sicherzustellen, dass die innere, und nicht die äußere Tabelle verteilt wird. Siehe Suboptimale Datenverteilung.