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

Nutzungshinweise

EXPLAINDie Leistung wird manchmal durch die Zeit beeinflusst, die zum Erstellen temporärer Tabellen benötigt wird. Beispielsweise erfordert eine Abfrage, die die allgemeine Optimierung von Unterausdrücken verwendet, dass temporäre Tabellen erstellt und analysiert werden, um die EXPLAIN Ausgabe zurückzugeben. Der Abfrageplan ist vom Schema und der Statistik der temporären Tabellen abhängig. Daher kann die Ausführung des EXPLAIN Befehls für diesen Abfragetyp länger dauern als erwartet.

Sie können ihn EXPLAIN nur für die folgenden Befehle verwenden:

Der EXPLAIN Befehl schlägt fehl, wenn Sie ihn für andere SQL Befehle verwenden, z. B. für Datendefinitionssprache (DDL) oder Datenbankoperationen.

Die relativen EXPLAIN Produktionsstückkosten 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.

Verwenden EXPLAIN für RLS

Wenn eine Abfrage eine Tabelle enthält, die Sicherheitsrichtlinien (RLS) auf Zeilenebene unterliegt, EXPLAIN wird ein spezieller RLS SecureScan Knoten angezeigt. Amazon Redshift protokolliert denselben Knotentyp auch in der EXPLAIN Systemtabelle STL _. EXPLAINenthüllt nicht das RLS Prädikat, das für dim_tbl gilt. Der RLS SecureScan 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 SecureScan Knoten.

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 der Abfragepläne zu ermöglichen, die unterliegenRLS, bietet Amazon Redshift die EXPLAIN RLS Systemberechtigungen. Benutzer, denen diese Berechtigung erteilt wurde, können vollständige Abfragepläne einsehen, die auch RLS Prädikate enthalten.

Das folgende Beispiel zeigt, dass ein zusätzlicher Seq-Scan unterhalb des RLS SecureScan Knotens auch das RLS Policy-Prä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 EXPLAIN RLS Berechtigung einem Benutzer erteilt wird, protokolliert Amazon Redshift den vollständigen Abfrageplan einschließlich RLS Prädikaten in der Systemtabelle STL _EXPLAIN. Abfragen, die ausgeführt werden, während diese Berechtigung nicht erteilt wurde, werden ohne interne Daten protokolliert. RLS Durch das Erteilen oder Entfernen der EXPLAIN RLS Berechtigung wird nichts daran geändert, was Amazon Redshift bei STL _ EXPLAIN für frühere Abfragen protokolliert hat.

AWS Lake Formation- RLS geschützte Redshift-Beziehungen

Das folgende Beispiel zeigt einen SecureScan LF-Knoten, mit dem Sie die RLS Beziehungen zwischen Lake Formation und Lake 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

Im folgenden Beispiel wird der Abfrageplan für eine Abfrage zurückgegeben, bei der dieEVENTID, EVENTNAMEVENUEID, und VENUENAME aus den VENUE Tabellen EVENT und ausgewählt werden:

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)