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.
EXPLAIN
Zeigt den Ausführungsplan für eine Abfrageanweisung an, ohne die Abfrage auszuführen. Informationen zum Arbeitsablauf für die Abfrageanalyse finden Sie unter Workflow zur Analyse von Abfragen.
Syntax
EXPLAIN [ VERBOSE ] query
Parameter
- VERBOSE
-
Zeigt den vollständigen Abfrageplan und nicht nur eine Zusammenfassung an.
- query
-
Die Abfrageanweisung, die erklärt werden soll. Bei der Abfrage kann es sich um eine SELECT-, INSERT-, CREATE TABLE AS-, UPDATE- oder DELETE-Anweisung handeln.
Nutzungshinweise
Die Leistung von EXPLAIN wird manchmal von der Zeit beeinflusst, die benötigt wird, um temporäre Tabellen zu erstellen. Beispielsweise müssen für eine Abfrage, die die allgemeine Unterausdruckoptimierung verwendet, temporäre Tabellen erstellt und analysiert werden, um die EXPLAIN-Ausgabe zurückgeben zu können. Der Abfrageplan ist vom Schema und der Statistik der temporären Tabellen abhängig. Daher benötigt der EXPLAIN-Befehl für diese Art von Abfrage möglicherweise länger für die Ausführung als erwartet.
Sie können EXPLAIN nur für die folgenden Befehle verwenden:
-
SELECT
-
SELECT INTO
-
CREATE TABLE AS
-
INSERT
-
AKTUALISIERUNG
-
DELETE
Der Befehl EXPLAIN ist nicht erfolgreich, wenn Sie ihn für andere SQL-Befehle verwenden, wie Data Definition Language (DDL)- oder Datenbankoperationen.
Die relativen Einheitskosten der EXPLAIN-Ausgabe werden von Amazon Redshift verwendet, um einen Abfrageplan auszuwählen. Amazon Redshift vergleicht die Größen verschiedener Ressourcenschätzungen, um den Plan zu ermitteln.
Abfrageplanung und Ausführungsschritte
Der Ausführungsplan für eine bestimmte Amazon-Redshift-Abfrageanweisung unterteilt Ausführung und Berechnung einer Abfrage in eine definierte Abfolge von Schritten und Tabellenoperationen, die schließlich einen endgültigen Ergebnissatz für die Abfrage zurückgeben. Informationen zur Abfrageplanung finden Sie unter Verarbeitung von Abfragen.
In der folgenden Tabelle wird eine Übersicht über die Schritte bereitgestellt, die Amazon Redshift für die Entwicklung eines Ausführungsplans für eine Abfrage verwenden kann, die von einem Benutzer zur Ausführung abgesendet wird.
| EXPLAIN-Operatoren | Abfrageausführungsschritte | Beschreibung |
|---|---|---|
| SCAN: | ||
| Sequenzieller Scan | scan | Amazon-Redshift-Beziehungs-Scan- oder Tabellen-Scan-Operator oder -Schritt. Scannt die gesamte Tabelle sequenziell von Anfang bis Ende und evaluiert darüber hinaus Abfrageeinschränkungen für jede Zeile (Filter), wenn mit der WHERE-Klausel angegeben. Wird auch für die Ausführung von INSERT-, UPDATE- und DELETE-Anweisungen verwendet. |
| JOINS: Amazon Redshift verwendet unterschiedliche Join-Operatoren, abhängig vom physischen Design der Tabellen, für die ein Join-Vorgang ausgeführt wird, vom Speicherort der Daten, die für den Join benötigt werden, und von den spezifischen Attributen der Abfrage selbst. Unterabfrage-Scan – Unterabfrage-Scans und Anfügungen werden verwendet, um UNION-Abfragen auszuführen. | ||
| Nested Loop | nloop | Dies ist der am wenigsten optimale Join; wird vor allem für Kreuz-Joins (kartesische Produkte; ohne Join-Bedingung) und einige Ungleichheits-Joins verwendet. |
| Hash Join | hjoin | Wird auch für interne Joins sowie externe Joins nach links und rechts verwendet und in der Regel schneller ausgeführt als ein Join über eine verschachtelte Schleife. Hash-Joins lesen die externe Tabelle, führen einen Hash-Vorgang für die angeschlossene Spalte aus und suchen Übereinstimmungen in der internen Hash-Tabelle. Dieser Schritt kann auf die Festplatte übergreifen. (Der interne Input von hjoin ist ein Hash-Schritt, der festplattenbasiert sein kann.) |
| Merge Join | mjoin | Wird auch für interne und externe Joins verwendet (für Join-Tabellen, die anhand der Join-Spalten verteilt und sortiert werden). In der Regel ist dies der schnellste Join-Algorithmus von Amazon Redshift ohne Berücksichtigung anderer Kostenüberlegungen. |
| AGGREGATION: Operatoren und Schritte, die für Abfragen verwendet werden, die zusammengefasste Funktionen und GROUP BY-Vorgänge verwenden. | ||
| Aggregate | aggr | Operator/Schritt für skalare Zusammenfassungsfunktionen. |
| HashAggregate | aggr | Operator/Schritt für gruppierte Zusammenfassungsfunktionen. Kann über die Festplatte ausgeführt werden, wenn die Hash-Tabelle auf die Festplatte übergreift. |
| GroupAggregate | aggr | Ein Operator, der manchmal für gruppierte Zusammenfassungsabfragen gewählt wird, wenn die Amazon-Redshift-Konfigurationseinstellung für die Einstellung force_hash_grouping nicht aktiviert ist. |
| SORT: Operatoren und Schritte, die verwendet werden, wenn Abfragen Ergebnissätze sortieren oder zusammenführen müssen. | ||
| Sortierung | sort | „sort“ führt die von der ORDER BY-Klausel angegebene Sortierung sowie weitere Operationen wie UNION und Joins aus. Kann von der Festplatte aus ausgeführt werden. |
| Merge | merge | Erstellt die abschließenden sortierten Ergebnisse einer Abfrage auf der Basis zwischenzeitlicher sortierter Ergebnisse, die von parallel ausgeführten Operationen abgeleitet werden. |
| EXCEPT-, INTERSECT- und UNION-Operationen: | ||
| SetOp Außer [Distinct] | hjoin | Wird für EXCEPT-Abfragen verwendet. Kann über die Festplatte ausgeführt werden, da der Eingabe-Hash festplattenbasiert sein kann. |
| Hash Intersect [Distinct] | hjoin | Wird für INTERSECT-Abfragen verwendet. Kann über die Festplatte ausgeführt werden, da der Eingabe-Hash festplattenbasiert sein kann. |
| Append [All |Distinct] | save | Eine Anfügung, die mit dem Unterabfrage-Scan ausgeführt wird, um UNION- und UNION ALL-Abfragen zu implementieren. Kann aufgrund von „save“ über die Festplatte ausgeführt werden. |
| Verschiedenes/Sonstiges: | ||
| Hash | hash | Wird für interne Joins sowie externe Joins nach links und rechts verwendet (stellt Eingaben für einen Hash-Join bereit). Der Hash-Operator erstellt die Hash-Tabelle für die interne Tabelle eines Join. (Die interne Tabelle ist die Tabelle, die auf Übereinstimmungen überprüft wird und im Fall eines Join zweier Tabellen in der Regel die kleinere der beiden Tabellen ist.) |
| Limit | limit | Evaluiert die Limit-Klausel. |
| Materialize | save | Setzt Zeilen für die Eingabe für Joins mit verschachtelten Schleifen und einige Zusammenführungs-Joins um. Kann von der Festplatte aus ausgeführt werden. |
| -- | parse | Wird verwendet, um während des Ladens Eingabedaten in Textform zu analysieren. |
| -- | project | Wird verwendet, um Spalten und Datenverarbeitungsausdrücke, d. h. Projektdaten, neu anzuordnen. |
| Ergebnis | -- | Führt skalare Funktionen aus, für die kein Tabellenzugriff erforderlich ist. |
| -- | return | Gibt Zeilen an den Leader oder Client zurück. |
| Subplan | -- | Wird für bestimmte Unterabfragen verwendet. |
| Unique | eindeutig | Beseitigt Duplikate aus SELECT DISTINCT- und UNION-Abfragen. |
| Window | window | Datenverarbeitung für Aggregation und Einstufung von Fensterfunktionen. Kann von der Festplatte aus ausgeführt werden. |
| Netzwerkoperationen: | ||
| Network (Broadcast) | bcast | Broadcast ist auch ein Attribut von Join Explain-Operatoren und -Schritten. |
| Network (Distribute) | dist | Verteilung von Zeilen an Datenverarbeitungsknoten für die parallele Verarbeitung durch ein Data Warehouse-Cluster. |
| Network (Send to Leader) | return | Sendet die Ergebnisse zur weiteren Verarbeitung an den Leader zurück. |
| DML-Operationen (Operatoren, die Daten ändern): | ||
| Insert (unter Verwendung des Ergebnisses) | insert | Fügt Daten ein. |
| Delete (Scan + Filter) | delete | Löscht Daten. Kann von der Festplatte aus ausgeführt werden. |
| Update (Scan + Filter) | delete, insert | Wird als Lösch- und Einfügevorgang implementiert. |
Verwendung von EXPLAIN für RLS
Wenn eine Abfrage eine Tabelle enthält, die RLS-Richtlinien (Row Level Security) unterliegt, zeigt EXPLAIN einen speziellen RLS-Knoten an. SecureScan Amazon Redshift protokolliert denselben Knotentyp auch in der STL_EXPLAIN-Systemtabelle. EXPLAIN enthüllt nicht das RLS-Prädikat, das für dim_tbl gilt. Der SecureScan RLS-Knotentyp dient als Indikator dafür, dass der Ausführungsplan zusätzliche Operationen enthält, die für den aktuellen Benutzer unsichtbar sind.
Das folgende Beispiel zeigt einen RLS-Knoten SecureScan .
EXPLAIN SELECT D.cint FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k WHERE F.k_dim / 10 > 0; QUERY PLAN ------------------------------------------------------------------------ XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4) Hash Cond: ("outer".k_dim = "inner"."k") -> *XN* *RLS SecureScan f (cost=0.00..0.14 rows=2 width=4)* Filter: ((k_dim / 10) > 0) -> XN Hash (cost=0.07..0.07 rows=2 width=8) -> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8) Filter: (("k" / 10) > 0)
Um eine vollständige Untersuchung von Abfrageplänen zu ermöglichen, die RLS unterliegen, bietet Amazon Redshift die EXPLAIN-RLS-Systemberechtigungen an. Benutzer, denen diese Berechtigung erteilt wurde, können vollständige Abfragepläne prüfen, die auch RLS-Prädikate enthalten.
Das folgende Beispiel zeigt, dass ein zusätzlicher Seq-Scan unterhalb des SecureScan RLS-Knotens auch das RLS-Richtlinienprädikat (k_dim > 1) beinhaltet.
EXPLAIN SELECT D.cint FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k WHERE F.k_dim / 10 > 0; QUERY PLAN --------------------------------------------------------------------------------- XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4) Hash Cond: ("outer".k_dim = "inner"."k") *-> XN RLS SecureScan f (cost=0.00..0.14 rows=2 width=4) Filter: ((k_dim / 10) > 0)* -> *XN* *Seq Scan on fact_tbl rls_table (cost=0.00..0.06 rows=5 width=8) Filter: (k_dim > 1)* -> XN Hash (cost=0.07..0.07 rows=2 width=8) -> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8) Filter: (("k" / 10) > 0)
Während die Berechtigung EXPLAIN RLS einem Benutzer erteilt wird, protokolliert Amazon Redshift den vollständigen Abfrageplan einschließlich RLS-Prädikate in der STL_EXPLAIN-Systemtabelle. Abfragen, die ausgeführt werden, während diese Berechtigung nicht erteilt ist, werden ohne RLS-Interna protokolliert. Das Erteilen oder Entfernen der EXPLAIN RLS-Berechtigung ändert nichts daran, was Amazon Redshift in STL_EXPLAIN für frühere Abfragen protokolliert hat.
AWS Lake Formation-RLS-geschützte Redshift-Relationen
Das folgende Beispiel zeigt einen SecureScan LF-Knoten, mit dem Sie die Beziehungen zwischen Lake Formation und RLS anzeigen können.
EXPLAIN SELECT * FROM lf_db.public.t_share WHERE a > 1; QUERY PLAN --------------------------------------------------------------- XN LF SecureScan t_share (cost=0.00..0.02 rows=2 width=11) (2 rows)
Beispiele
Anmerkung
Für diese Beispiele kann sich die Beispielausgabe abhängig von der Amazon-Redshift-Konfiguration unterscheiden.
Im folgenden Beispiel wird der Abfrageplan für eine Abfrage zurückgegeben, die EVENTID, EVENTNAME, VENUEID und VENUENAME aus den Tabellen EVENT und VENUE auswählt:
explain select eventid, eventname, event.venueid, venuename from event, venue where event.venueid = venue.venueid;
QUERY PLAN -------------------------------------------------------------------------- XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23) -> XN Hash (cost=2.02..2.02 rows=202 width=22) -> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22) (5 rows)
Im folgenden Beispiel wird der Abfrageplan für dieselbe Abfrage mit Verbose-Ausgabe zurückgegeben:
explain verbose select eventid, eventname, event.venueid, venuename from event, venue where event.venueid = venue.venueid;
QUERY PLAN -------------------------------------------------------------------------- {HASHJOIN :startup_cost 2.52 :total_cost 58653620.93 :plan_rows 8712 :plan_width 43 :best_pathkeys <> :dist_info DS_DIST_OUTER :dist_info.dist_keys ( TARGETENTRY { VAR :varno 2 :varattno 1 ... XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43) Hash Cond: ("outer".venueid = "inner".venueid) -> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23) -> XN Hash (cost=2.02..2.02 rows=202 width=22) -> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22) (519 rows)
Im folgenden Beispiel wird der Abfrageplan für eine CREATE TABLE AS (CTAS)-Anweisung zurückgegeben:
explain create table venue_nonulls as select * from venue where venueseats is not null; QUERY PLAN ----------------------------------------------------------- XN Seq Scan on venue (cost=0.00..2.02 rows=187 width=45) Filter: (venueseats IS NOT NULL) (2 rows)
