Ü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 in der LIMIT-Klausel verwendeten Wert heraufsetzen, um sicherzustellen, dass die Abfrage berücksichtigt wird.

  2. Wählen Sie Zeilen aus STL_ALERT_EVENT_LOG für Ihre Abfrage aus:

    Select * from stl_alert_event_log where query = MyQueryID;
  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

    In STL_ALERT_EVENT_LOG sind nur Abfragen mit erkannten Problemen aufgeführt.

    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 Befehl ANALYZE 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 Befehl VACUUM aus, um den Speicherplatz für die gelöschten Zeilen 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. Es wurde eine große Anzahl von Zeilen über das Netzwerk verteilt: 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.
    In dem Abfrageplan wird ein Umverteilungsstil von DS_DIST_ALL_INNER angezeigt, der die serielle Ausführung erzwingt, da die gesamte innere Tabelle an 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.