Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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](c-query-analysis-process.md). ## Syntax ``` EXPLAIN [ VERBOSE ] query ``` ## Parameters 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](c-query-processing.md). 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/r_EXPLAIN.html) ## 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\$1EXPLAIN-Systemtabelle. EXPLAIN enthüllt nicht das RLS-Prädikat, das für dim\$1tbl 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\$1dim > 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\$1EXPLAIN-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\$1EXPLAIN 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) ```