Amazon Redshift wird die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr unterstützen. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zu den Einzelheiten zum Ende der Lebensdauer und zu den Migrationsoptionen von Python finden Sie in dem Blogbeitrag
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.
Verbessern der Abfrageleistung
Nachstehend finden Sie eine Liste häufig auftretender Probleme, die die Abfrageleistung in Amazon Redshift beeinträchtigen, und Möglichkeiten zu ihrer Diagnose und Behandlung.
Themen
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 dieses Problem zu beheben, überprüfen Sie Ihre Abfrage auf Cross-Joins und entfernen Sie sie nach Möglichkeit. Cross-joins sind Verknüpfungen ohne Join-Bedingung, die das kartesische Produkt zweier Tabellen ergeben. 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 Sortierschlüssel.
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 Datenverteilung zur Abfrageoptimierung.
Ungenügende Speicherzuteilung für die Abfrage
Wenn eine Abfrage mehr Speicher benötigt, als ihr zugewiesen ist, schreibt Amazon Redshift die überschüssigen Zwischenergebnisse auf die Festplatte. Dies wird als Verschütten auf die Festplatte bezeichnet. Amazon Redshift schreibt verschüttete Daten zuerst auf die lokale Festplatte. Wenn sie die lokale Festplattenkapazität überschreiten, laufen die Daten zu Amazon S3 über. Bei den Abfrageschritten, bei denen die Wahrscheinlichkeit am größten ist, dass Daten übertragen werden, sind Hash-Joins, Aggregationen (wie GROUP BY und DISTINCT), Fensterfunktionen und Sortierungen (ORDER BY) bei großen Datensätzen.
Wenn Daten auf die Festplatte übertragen werden, wird die Abfrage verlangsamt, da der Festplattenzugriff viel langsamer ist als der Zugriff auf den Arbeitsspeicher. Da die lokale Festplatte und die I/O Bandbreite im gesamten Cluster gemeinsam genutzt werden, kann ein hoher Datenverlust auch andere Abfragen verlangsamen, die gleichzeitig ausgeführt werden. Durch die Reduzierung von Datenverlusten werden sowohl die Latenz einzelner Abfragen als auch der Gesamtdurchsatz des Clusters verbessert.
Identifizieren Sie Anfragen, die überlaufen. Fragen Sie die spilled_block_remote_disk Spalten SYS_QUERY_DETAIL und ab spilled_block_local_disk und überprüfen Sie sie. Abfragen mit einem hohen spilled_block_remote_disk Wert gehen über die lokale Festplatte hinaus und profitieren am meisten von der Optimierung. Auf einem bereitgestellten Cluster können Sie die query_temp_blocks_to_disk Metrik auch unter überprüfen. SVL_QUERY_METRICS_SUMMARY
Wie lässt sich das Überlaufen von Festplatten reduzieren
-
Reduzieren Sie das Volumen der Zwischendaten. Filtern Sie früher, wählen Sie nur die Spalten aus, die Sie benötigen, und aggregieren Sie nach Möglichkeit vorab, sodass weniger Zeilen in Verknüpfungen, Aggregationen und Sortierungen einfließen.
-
Teilen Sie umfangreiche Abfragen in Schritte auf. Materialisieren Sie Zwischenergebnisse in temporären Tabellen (CREATE TEMP TABLE AS), sodass jeder Schritt mit einem geringeren Speicherbedarf ausgeführt wird und die Wahrscheinlichkeit geringer ist, dass Daten verloren gehen. Geben Sie der temporären Tabelle einen geeigneten Verteilungs- und Sortierschlüssel und führen Sie ANALYZE aus, damit die nachfolgenden Schritte effizient ausgeführt werden.
-
Geben Sie der Abfrage mehr Speicher, indem Sie die Anzahl der Steckplätze vorübergehend erhöhen, wenn Sie manuelles WLM verwenden (siehewlm_query_slot_count).
-
Fügen Sie Knoten hinzu oder wechseln Sie zu einem größeren Knotentyp, wenn ein Überlaufen Ihres Datenvolumens unvermeidlich ist.
Überwachen Sie Datenlecks proaktiv. Erstellen Sie eine Regel zur Abfrageüberwachung (QMR) für die Metrik. query_temp_blocks_to_disk Diese Metrik misst den temporären Festplattenspeicher, der für Zwischenergebnisse verwendet wird, in Blöcken von 1 MB. Wählen Sie dann eine Aktion aus:
- log
-
Zeichnet die Abfrage zur Überprüfung auf.
- Abbruch
-
Stoppt die Abfrage, bevor sie andere Workloads beeinträchtigt.
Beispielsweise protokolliert query_temp_blocks_to_disk > 100000 (ca. 100 GB) Abfragen, bei denen ungewöhnlich große Datenmengen übertragen werden, oder bricht sie ab. Passen Sie den Schwellenwert an Ihren Cluster oder Ihre Arbeitsgruppe an. Konfigurieren Sie QMR auf einem bereitgestellten Cluster über Ihre WLM-Warteschlangen. Konfigurieren Sie es auf Redshift Serverless über Grenzwerte für Arbeitsgruppen-Abfragen. Weitere Informationen finden Sie unter WLM-Abfrageüberwachungsregeln.
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.
