Analysieren des Abfrageplans - 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.

Analysieren des Abfrageplans

Um den Abfrageplan zu analysieren, sollten Sie sich zunächst damit vertraut machen, wie diese Pläne zu lesen sind. Wenn Sie sich erstmals mit der Interpretation von Abfrageplänen beschäftigen, empfehlen wir Ihnen, Abfrageplan zu lesen, bevor Sie fortfahren.

Führen Sie den Befehl EXPLAIN aus, um den Abfrageplan abzurufen. Folgen Sie diesen Anweisungen, um die Daten in dem Abfrageplan zu analysieren:

  1. Identifizieren Sie die Schritte mit den höchsten Kosten. Konzentrieren Sie sich bei den restlichen Anweisungen darauf, diese Schritte zu optimieren.

  2. Achten Sie auf die Join-Varianten:

    • Nested Loop (Verschachtele Schleife): Verschachtelte Schleifen treten häufig auf, weil eine Bedingung für die Join-Operation fehlt. Empfohlene Lösungen finden Sie unter Verschachtelte Schleife.

    • Hash and Hash Join (Hash und Hash-Join): Hash-Joins werden bei Join-Operationen für Tabellen verwendet, bei denen die Join-Spalten weder Verteilungsschlüssel noch Sortierschlüssel sind. Empfohlene Lösungen finden Sie unter Hash join.

    • Merge Join (Zusammenführungs-Join): keine Änderung erforderlich.

  3. Achten Sie darauf, welche Tabellen für den inneren Join verwendet werden, und welche für den äußeren. Die Abfrage-Engine verwendet normalerweise die kleinere Tabelle für den inneren Join und die größere für den äußeren. Wenn die Abfrage offensichtlich die beiden Tabellen falsch zuordnet, besteht die Möglichkeit, dass die Datenbankstatistik nicht mehr aktuell ist. Empfohlene Lösungen finden Sie unter Die Tabellenstatistik fehlt oder ist veraltet..

  4. Schauen Sie nach, ob bestimmte Sortieroperationen besonders teuer sind. Falls dies der Fall ist, finden Sie empfohlene Lösungen unter Unsortierte oder falsch sortierte Zeilen.

  5. Sehen Sie nach den folgenden Broadcastoperatoren, wenn es Operationen mit hohen Kosten gibt:

    • DS_BCAST_INNER: Zeigt an, dass die Tabelle an alle Computingknoten übertragen wird. Dies ist bei kleinen Tabellen unproblematisch, bei großen Tabellen jedoch nicht ideal.

    • DS_DIST_ALL_INNER: Gibt an, dass ein einziger Slice den gesamten Workload ausführt.

    • DS_DIST_BOTH: Gibt an, dass Daten stark umverteilt werden.

    Empfohlene Lösungen für diese Situationen finden Sie unter Suboptimale Datenverteilung.