Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Mostra il piano di esecuzione per l'istruzione di una query senza eseguire la query. Per informazioni sul flusso di lavoro di analisi delle query, consulta Flusso di lavoro dell'analisi di query.
Sintassi
EXPLAIN [ VERBOSE ] query
Parametri
- VERBOSE
-
Visualizza il piano di query completo anziché solo un riepilogo.
- query
-
Istruzione di query da spiegare. La query può essere un'istruzione SELECT, INSERT, CREATE TABLE AS, UPDATE o DELETE.
Note per l'utilizzo
Le prestazioni di EXPLAIN sono talvolta influenzate dal tempo necessario per creare le tabelle temporanee. Ad esempio, una query che utilizza l'ottimizzazione dell'espressione secondaria comune richiede che vengano create e analizzate le tabelle temporanee per restituire l'output di EXPLAIN. Il piano di query dipende dallo schema e dalle statistiche delle tabelle temporanee. Pertanto, il comando EXPLAIN per questo tipo di query potrebbe impiegare più tempo del previsto.
Puoi utilizzare EXPLAIN solo per i seguenti comandi:
-
SELECT
-
SELECT INTO
-
CREATE TABLE AS
-
INSERT
-
UPDATE
-
DELETE
Il comando EXPLAIN avrà esito negativo se lo si utilizza per altri comandi SQL, ad esempio operazioni di database o DDL (Data Definition Language).
I costi unitari relativi all'output EXPLAIN vengono utilizzati da Amazon Redshift per scegliere un piano di query. Amazon Redshift confronta le dimensioni delle varie stime delle risorse per determinare il piano.
Pianificazione di query e fasi di esecuzione
Il piano di esecuzione per una istruzione di query Amazon Redshift specifica suddivide l'esecuzione e il calcolo di una query in una sequenza discreta di fasi e operazioni di tabella che alla fine produce un set di risultati finali per la query. Per informazioni sulla pianificazione di query, consultare Elaborazione query.
La seguente tabella fornisce un riepilogo delle fasi che Amazon Redshift può utilizzare nello sviluppo di un piano di esecuzione per qualsiasi query inviata dall'utente per l'esecuzione.
| Operatori EXPLAIN | Fasi di esecuzione di query | Descrizione |
|---|---|---|
| SCAN: | ||
| Scansione sequenziale | scan | Operatore o fase della scansione della relazione o della tabella di Amazon Redshift. Scansiona l'intera tabella in sequenza dall'inizio alla fine; valuta anche i vincoli di query per ogni riga (Filtro) se specificato con la clausola WHERE. Usato anche per eseguire le Istruzioni INSERT, UPDATE e DELETE. |
| JOINS: Amazon Redshift usa differenti operatori di join secondo il progetto fisico delle tabelle combinate, la posizione dei dati necessari per il join e gli attributi specifici della stessa query. Scansione di sottoquery: la scansione e l'aggiunta delle sottoquery vengono utilizzate per eseguire query UNION. | ||
| Loop nidificato | nloop | Il join meno ottimale, utilizzato principalmente per i cross join (prodotti cartesiani senza una condizione di join) e per alcuni join di disuguaglianza. |
| Hash join | hjoin | Utilizzato anche per gli inner join e per gli outer join destra e sinistra e normalmente più veloce di un join loop nidificato. Hash Join legge la tabella esterna, applica l'hash alla colonna di join e trova corrispondenze nella tabella interna hash. La fase può essere versata sul disco. L'input interno di hjoin è una fase di hash che può essere basata su disco. |
| Merge join | mjoin | Utilizzato anche per gli inner join e gli outer join (per le tabelle di join che sono sia distribuite che ordinate sulle colonne di unione). In genere il più veloce algoritmo join di Amazon Redshift, escludendo altre considerazioni sui costi. |
| AGGREGATION: operatori e fasi utilizzati per le query che implicano le funzioni aggregate e le operazioni GROUP BY. | ||
| Aggregazione | aggr | Operatore/Fase per le funzioni aggregate scalari. |
| HashAggregate | aggr | Operatore/Fase per le funzioni aggregate raggruppate. Può operare dal disco in virtù del versamento della tabella di hash sul disco. |
| GroupAggregate | aggr | Operatore a volte scelto per le query aggregate raggruppate se l'impostazione di configurazione di Amazon Redshift per l'impostazione force_hash_grouping è disattivata. |
| SORT: operatori e fasi utilizzati quando le query devono ordinare o unire gli insiemi dei risultati. | ||
| Ordina | sort | Sort esegue l'ordinamento specificato dalla clausola ORDER BY UNIONs e altre operazioni come i join. Può operare dal disco. |
| Unione | merge | Produce risultati ordinati finali di una query basata sui risultati ordinati intermedi che derivano dalle operazioni eseguite in parallelo. |
| Operazioni EXCEPT, INTERSECT e UNION: | ||
| SetOp Eccetto [Distinct] | hjoin | Utilizzato per eseguire le query EXCEPT. Può operare dal disco in virtù del fatto che l'hash di input può essere basato su disco. |
| Hash Intersect [Distinct] | hjoin | Utilizzato per eseguire le query INTERSECT. Può operare dal disco in virtù del fatto che l'hash di input può essere basato su disco. |
| Append [All |Distinct] | save | Append usato con la scansione di sottoquery per implementare le query UNION e UNION ALL. Può operare dal disco in virtù di "save". |
| Varie/Altro: | ||
| Hash | hash | Utilizzato per gli inner join e per gli outer join destra e sinistra (fornisce l'input a un join hash). L'operatore Hash crea la tabella hash per la tabella interna di un join. La tabella interna è la tabella che viene controllata per le corrispondenze e, in un join di due tabelle, è solitamente la più piccola delle due. |
| Limite | limit | Calcola la clausola LIMIT. |
| Materialize | save | Materializza le righe per l'input dei join di loop nidificati e alcuni merge join. Può operare dal disco. |
| -- | parse | Utilizzato per analizzare i dati di input testuali durante un caricamento. |
| -- | project | Utilizzato per riorganizzare le colonne e calcolare le espressioni, ovvero i dati del progetto. |
| Risultato | -- | Esegue le funzioni scalari che non implicano alcun accesso di tabella. |
| -- | return | Restituisce le righe al nodo principale o al client. |
| Subplan | -- | Utilizzato per determinate sottoquery. |
| Unique | unique | Elimina i duplicati dalle query SELECT DISTINCT e UNION. |
| Window | window | Calcola le funzioni di aggregazione e di classificazione della finestra. Può operare dal disco. |
| Operazioni di rete: | ||
| Network (Broadcast) | bcast | Broadcast è anche un attributo di operatori e fasi Join Explain. |
| Network (Distribute) | dist | Distribuisce le righe ai nodi di calcolo per l'elaborazione parallela dal cluster del data warehouse. |
| Network (Send to Leader) | return | Invia risultati nuovamente al nodo principale per elaborazioni future. |
| Operazioni DML (operatori che modificano i dati): | ||
| Insert (using Result) | insert | Inserisce i dati. |
| Delete (Scan + Filter) | Elimina | Elimina i dati. Può operare dal disco. |
| Update (Scan + Filter) | delete, insert | Implementato come delete e insert. |
Utilizzo di EXPLAIN per RLS
Se una query contiene una tabella soggetta a politiche di sicurezza a livello di riga (RLS), EXPLAIN visualizza un nodo RLS speciale. SecureScan Amazon Redshift registra anche lo stesso tipo di nodo nella tabella di sistema STL_EXPLAIN. EXPLAIN non rivela il predicato RLS che si applica a dim_tbl. Il tipo di SecureScan nodo RLS serve da indicatore del fatto che il piano di esecuzione contiene operazioni aggiuntive invisibili all'utente corrente.
L'esempio seguente illustra un nodo RLS 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)Per consentire un'analisi completa dei piani di query soggetti a RLS, Amazon Redshift offre le autorizzazioni di sistema EXPLAIN RLS. Gli utenti a cui è stata concessa questa autorizzazione possono esaminare piani di query completi che includono anche predicati RLS.
L'esempio seguente illustra un Seq Scan aggiuntivo sotto il SecureScan nodo RLS che include anche il predicato della policy RLS (k_dim > 1).
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)Sebbene l'autorizzazione EXPLAIN RLS sia concessa a un utente, Amazon Redshift registra il piano di query completo, inclusi i predicati RLS, nella tabella di sistema STL_EXPLAIN. Le query che vengono eseguite mentre questa autorizzazione non è concessa verranno registrate senza interni RLS. La concessione o la rimozione dell'autorizzazione EXPLAIN RLS non modificherà ciò che Amazon Redshift ha registrato su STL_EXPLAIN per le query precedenti.
Relazioni Redshift protette da AWS Lake Formation-RLS
L'esempio seguente illustra un SecureScan nodo LF, che è possibile utilizzare per visualizzare le relazioni Lake Formation-RLS.
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)Esempi
Nota
Per questi esempi, l'output di esempio potrebbe variare a seconda della configurazione di Amazon Redshift.
L'esempio seguente restituisce il piano di query per una query che seleziona EVENTID, EVENTNAME, VENUEID e VENUENAME dalle tabelle EVENT e VENUE:
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)L'esempio seguente restituisce il piano di query per la stessa query con output dettagliato:
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)L'esempio seguente restituisce il piano di query per un'istruzione CREATE TABLE AS (CTAS):
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)