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.

Einen Abfrageplan erstellen und interpretieren

Sie können den Abfrageplan verwenden, um Informationen über die Einzeloperationen zu erhalten, die zur Ausführung einer Abfrage benötigt werden. Wir empfehlen, sich zunächst mit den Grundlagen der Verarbeitung von Abfragen und der Erstellung von Abfrageplänen durch Amazon Redshift vertraut zu machen, bevor Sie mit Abfrageplänen arbeiten. Weitere Informationen finden Sie unter Workflow der Abfrageplanung und -ausführung.

Um einen Abfrageplan zu erstellen, führen Sie einen EXPLAIN-Befehl, gefolgt von der Abfragetext, aus. Der Abfrageplan enthält die folgenden Informationen:

Der EXPLAIN Befehl führt die Abfrage nicht wirklich aus. Der Befehl zeigt lediglich den Plan an, den Amazon Redshift ausführt, wenn die Abfrage unter den aktuellen Betriebsbedingungen ausgeführt wird. Wenn Sie für eine Tabelle das Schema oder Daten ändern und dann erneut ANALYZE ausführen, um die statistischen Metadaten zu aktualisieren, sieht der Abfrageplan möglicherweise anders aus.

Der von ausgegebene Abfrageplan EXPLAIN ist eine vereinfachte, allgemeine Ansicht der Abfrageausführung. Die Details zur parallelen Verarbeitung der Abfragen werden nicht angezeigt. Um detaillierte Informationen anzuzeigen, führen Sie die Abfrage selbst aus und rufen Sie dann die zusammenfassenden Informationen zur Abfrage aus der REPORT Ansicht SVL QUERY _ SVL _ SUMMARY oder QUERY _ _ ab. Weitere Informationen zur Verwendung dieser Ansichten finden Sie unter Analysieren des Abfragezusammenfassung.

Das folgende Beispiel zeigt die EXPLAIN Ausgabe für eine einfache GROUP BY-Abfrage in der EVENT Tabelle:

explain select eventname, count(*) from event group by eventname;

                            QUERY PLAN
-------------------------------------------------------------------
XN HashAggregate  (cost=131.97..133.41 rows=576 width=17)
  ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=17)

EXPLAINgibt die folgenden Metriken für jeden Vorgang zurück:

EXPLAINBetreiber

In diesem Abschnitt werden kurz die Operatoren beschrieben, die Sie in der EXPLAIN Ausgabe am häufigsten sehen. Eine vollständige Liste der Operatoren finden Sie EXPLAIN im Abschnitt SQL Befehle.

Sequenzieller Scan-Operator

Der sequenzielle Scan-Operator (Seq Scan) scannt eine Tabelle. Seq Scan scannt jede Spalte in der Tabelle sequentiell von Anfang bis Ende und wertet Abfrageeinschränkungen (in der WHERE Klausel) für jede Zeile aus.

Join-Operatoren

Amazon Redshift wählt Join-Operatoren abhängig vom physischen Design der Tabellen, für die die Join-Operation ausgeführt wird, vom Speicherort der Daten, die für den Join benötigt werden, und von den spezifischen Anforderungen der Abfrage selbst aus.

Aggregat-Operatoren

Der Abfrageplan verwendet die folgenden Operatoren in Abfragen, die Aggregatfunktionen und GROUP BY-Operationen beinhalten.

Sortieroperatoren

In dem Abfrageplan werden die folgenden Operatoren verwendet, wenn in Abfragen Ergebnissätze sortiert oder zusammengeführt werden sollen.

UNIONINTERSECT, und Operatoren EXCEPT

Der Abfrageplan verwendet die folgenden Operatoren für Abfragen, die Mengenoperationen mit UNIONINTERSECT, und beinhaltenEXCEPT.

Andere Operatoren

Die folgenden Operatoren kommen auch häufig in der EXPLAIN Ausgabe von Routineabfragen vor.

Schließt sich an EXPLAIN

Der Abfrageoptimierer verwendet verschiedene Varianten von Join-Operationen, je nachdem, wie die Abfrage und die zugrundeliegenden Tabellen strukturiert sind. Die EXPLAIN Ausgabe referenziert den Join-Typ, die verwendeten Tabellen und die Art und Weise, wie die Tabellendaten über den Cluster verteilt sind, um zu beschreiben, wie die Abfrage verarbeitet wird.

Beispiele für Join-Varianten

Die folgenden Beispiele zeigen die verschiedene Join-Varianten, die dem Abfrageoptimierer zur Verfügung stehen. Die Join-Variante in dem Abfrageplan hängt vom physischen Design der beteiligten Tabellen ab.

Beispiel: Hash-Join zweier Tabellen

Die folgende Abfrage verknüpft EVENT und bezieht sich CATEGORY auf die CATID Spalte. CATIDist der Verteilungs- und Sortierschlüssel fürCATEGORY, aber nicht fürEVENT. Ein Hash-Join wird EVENT als äußere Tabelle und CATEGORY als innere Tabelle ausgeführt. Da CATEGORY es sich um die kleinere Tabelle handelt, sendet der Planer während der Abfrageverarbeitung mithilfe von DS_ _ BCAST eine Kopie davon an die Rechenknoten. INNER Die Kosten für die Join-Operation machen den Großteil der kumulierten Kosten für den Plan aus.

explain select * from category, event where category.catid=event.catid;

                               QUERY PLAN
-------------------------------------------------------------------------
 XN Hash Join DS_BCAST_INNER  (cost=0.14..6600286.07 rows=8798 width=84)
   Hash Cond: ("outer".catid = "inner".catid)
   ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=35)
   ->  XN Hash  (cost=0.11..0.11 rows=11 width=49)
         ->  XN Seq Scan on category  (cost=0.00..0.11 rows=11 width=49)

Beispiel: Zusammenführungs-Join zweier Tabellen

Die folgende Abfrage verwendet ebenfalls SELECT *, verknüpft aber die LISTID Spalte SALES und LISTING verknüpft sie, wobei sowohl der Verteilungs- als auch der Sortierschlüssel für beide Tabellen festgelegt LISTID wurde. Es wird eine Zusammenführungsverknüpfung ausgewählt, und für die Verknüpfung ist keine Neuverteilung der Daten erforderlich (DS_ DIST _NONE).

explain select * from sales, listing where sales.listid = listing.listid;
QUERY PLAN
-----------------------------------------------------------------------------
XN Merge Join DS_DIST_NONE  (cost=0.00..6285.93 rows=172456 width=97)
  Merge Cond: ("outer".listid = "inner".listid)
  ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=44)
  ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=53)

Das folgende Beispiele illustriert die verschiedene Join-Varianten in derselben Abfrage. Wie im vorherigen Beispiel LISTING werden beide SALES zusammengeführt, aber die dritte Tabelle muss mit den Ergebnissen des Merge-Joins Hash-verknüpft werden. EVENT Auch hier fallen für den Hash-Join Kosten für die Rundsendung von Daten an.

explain select * from sales, listing, event
where sales.listid = listing.listid and sales.eventid = event.eventid;
                                  QUERY PLAN
----------------------------------------------------------------------------
XN Hash Join DS_BCAST_INNER  (cost=109.98..3871130276.17 rows=172456 width=132)
  Hash Cond: ("outer".eventid = "inner".eventid)
  ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6285.93 rows=172456 width=97)
        Merge Cond: ("outer".listid = "inner".listid)
        ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=44)
        ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=53)
  ->  XN Hash  (cost=87.98..87.98 rows=8798 width=35)
        ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=35)

Beispiel: Join-, Aggregat- und Sortieroperationen

Die folgende Abfrage führt eine Hash-Verknüpfung der EVENT Tabellen SALES und aus, gefolgt von Aggregations- und Sortieroperationen, um die gruppierte SUM Funktion und die ORDER BY-Klausel zu berücksichtigen. Der erste Sortieroperator wird parallel auf den Datenverarbeitungsknoten ausgeführt. Anschließend sendet der Network-Operator die Ergebnisse an den Führungsknoten, wo sie mit einer Merge-Operation zu einem sortierten Endergebnis zusammengeführt werden.

explain select eventname, sum(pricepaid) from sales, event 
where sales.eventid=event.eventid group by eventname
order by 2 desc;
                                           QUERY PLAN
---------------------------------------------------------------------------------
 XN Merge  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
  Merge Key: sum(sales.pricepaid)
  ->  XN Network  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
        Send to leader
        ->  XN Sort  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
              Sort Key: sum(sales.pricepaid)
              ->  XN HashAggregate  (cost=2815366577.07..2815366578.51 rows=576 width=27)
                    ->  XN Hash Join DS_BCAST_INNER  (cost=109.98..2815365714.80 rows=172456 width=27)
                          Hash Cond: ("outer".eventid = "inner".eventid)
                          ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=14)
                          ->  XN Hash  (cost=87.98..87.98 rows=8798 width=21)
                                ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=21)

Datenumverteilung

Die EXPLAIN Ausgabe für Verknüpfungen gibt auch eine Methode an, wie Daten innerhalb eines Clusters verschoben werden, um die Verknüpfung zu erleichtern. Diese Datenbewegung kann entweder eine Rundsendung oder eine Umverteilung sein. Bei einer Rundsendung werden die Datenwerte von der einen Seite des Joins von jedem Verarbeitungsknoten an jeden anderen Verarbeitungsknoten gesendet, sodass jeder Verarbeitungsknoten am Ende der Operation eine vollständige Kopie der Daten hat. Bei einer Umverteilung werden die jeweiligen Datenwerte von ihrer aktuellen Slice an eine neue Slice gesendet, die sich möglicherweise auf einem anderen Knoten befindet. Die Daten werden normalerweise entsprechend dem Verteilungsschlüssel der anderen Tabelle des Joins umverteilt, wenn eine der Spalten der Join-Operation dieser Verteilungsschlüssel ist. Wenn keine der beiden Tabellen Verteilungsschlüssel in der jeweils anderen Tabelle hat, werden entweder beide Tabellen verteilt, oder die innere Tabelle wird an alle Knoten rundgesendet.

Die EXPLAIN Ausgabe verweist auch auf innere und äußere Tabellen. Die innere Tabelle wird zuerst gescannt und wird weiter unten im Abfrageplan angezeigt. Die innere Tabelle ist die Tabelle, in der nach Übereinstimmungen gesucht wird. Sie wird normalerweise im Speicher gehalten und als Quelltabelle für Hash-Operationen verwendet. Falls möglich wird die kleiner der beiden Tabellen als innere Tabelle verwendet. Der äußeren Tabelle werden die Zeilen entnommen für die in der inneren Tabelle nach Übereinstimmungen gesucht wird. Sie wird normalerweise vom Datenträger gelesen. Der Abfrageoptimierer wählt die innere und äußere Tabelle auf der Grundlage von Datenbankstatistiken aus der letzten Ausführung des ANALYZE Befehls aus. Die Reihenfolge der Tabellen in der FROM Klausel einer Abfrage bestimmt nicht, welche Tabelle innerlich und welche äußerlich ist.

Die folgenden Attribute in Abfrageplänen ermöglichen zu identifizieren, welche Daten bei der Ausführung einer Abfrage bewegt werden: