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à.

Creazione e interpretazione di un piano di interrogazione

Per ottenere informazioni sulle operazioni individuali necessarie per eseguire una query, puoi utilizzare il piano di query. Prima di lavorare con il piano di query, consigliamo di capire in che modo Amazon Redshift gestisce l'elaborazione delle query e crea piani di query. Per ulteriori informazioni, consultare Pianificazione di query e flusso di lavoro di esecuzione.

Per creare un piano di query, esegui il comando EXPLAIN seguito dal testo di query corrente. Il piano di query rende le seguenti informazioni:

Il EXPLAIN comando non esegue effettivamente la query. Mostra solamente il piano che verrà eseguito da Amazon Redshift se la query viene eseguita nelle condizioni operative attuali. Se modifichi lo schema o i dati di una tabella ed esegui nuovamente il comando ANALYZE per aggiornare i metadati statistici, il piano di query potrebbe essere differente.

L'output del piano di query EXPLAIN è una visualizzazione semplificata e di alto livello dell'esecuzione delle query. Non illustra i dettagli dell'elaborazione di query parallela. Per visualizzare informazioni dettagliate, esegui la query stessa, quindi ottieni le informazioni di riepilogo della query dalla vista SVL _ QUERY _ SUMMARY o SVL _ QUERY _REPORT. Per ulteriori informazioni sull'utilizzo di queste visualizzazioni, consultare Analisi del riepilogo della query.

L'esempio seguente mostra l'EXPLAINoutput di una semplice query GROUP BY sulla EVENT tabella:

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)

EXPLAINrestituisce le seguenti metriche per ogni operazione:

EXPLAINoperatori

Questa sezione descrive brevemente gli operatori che vedete più spesso nell'EXPLAINoutput. Per un elenco completo degli operatori, EXPLAIN consultate la sezione SQL Comandi.

Operatore scansione sequenziale

L'operatore scansione sequenziale (Seq Scan) indica una scansione della tabella. Seq Scan analizza ogni colonna della tabella in sequenza dall'inizio alla fine e valuta i vincoli di interrogazione (nella clausola) per ogni riga. WHERE

Operatori di combinazione

Amazon Redshift seleziona gli operatori join basati sul progetto fisico delle tabelle combinate, la posizione dei dati necessari per il join e i requisiti specifici della stessa query.

Operatori di aggregazione

Il piano di query utilizza i seguenti operatori nelle query che coinvolgono funzioni aggregate e operazioni BY. GROUP

Operatori di ordinamento

Il piano di query utilizza i seguenti operatori quando le query devono ordinare o unire gli insiemi dei risultati.

UNIONe operatori INTERSECT EXCEPT

Il piano di interrogazione utilizza i seguenti operatori per le query che coinvolgono operazioni di set con UNIONINTERSECT, eEXCEPT.

Altri operatori

I seguenti operatori vengono inoltre visualizzati frequentemente nell'EXPLAINoutput delle query di routine.

Si unisce a EXPLAIN

L'ottimizzatore di query utilizza diversi tipi di combinazioni per recuperare i dati della tabella, a seconda della struttura della query e delle tabelle sottostanti. L'EXPLAINoutput fa riferimento al tipo di join, alle tabelle utilizzate e al modo in cui i dati della tabella vengono distribuiti nel cluster per descrivere come viene elaborata la query.

Esempi di tipo di join

I seguenti esempi mostrano i diversi tipi di combinazione che può utilizzare l'ottimizzatore di query. Il tipo di combinazione utilizzato nel piano della query dipende dal progetto fisico delle tabelle coinvolte.

Esempio: eseguire un hash join di due tabelle

La seguente query unisce EVENT e si trova CATEGORY sulla CATID colonna. CATIDè la chiave di distribuzione e ordinamento per CATEGORY ma non perEVENT. Un hash join viene eseguito utilizzando EVENT come tabella esterna e CATEGORY come tabella interna. Poiché CATEGORY è la tabella più piccola, il planner ne trasmette una copia ai nodi di calcolo durante l'elaborazione delle query utilizzando DS_ _. BCAST INNER Il costo di combinazione in questo esempio rappresenta la maggior parte del costo cumulativo del piano.

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)

Esempio: eseguire un merge join di due tabelle

Anche la seguente query utilizza SELECT *, ma unisce SALES e si trova LISTING sulla LISTID colonna, dove è LISTID stata impostata sia come chiave di distribuzione che come chiave di ordinamento per entrambe le tabelle. Viene scelto un merge join e non è richiesta alcuna ridistribuzione dei dati per il join (DISTDS_ _). 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)

L'esempio seguente dimostra i diversi tipi di combinazione all'interno della stessa query. Come nell'esempio precedente, SALES e LISTING vengono uniti tramite merge join, ma la terza tabella deve essere collegata EVENT tramite hash ai risultati del merge join. Ancora una volta, l'operatore merge join incorre in un costo di trasmissione.

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)

Esempi: Join, Aggregate e Sort

La seguente query esegue un hash join delle EVENT tabelle SALES and, seguito da operazioni di aggregazione e ordinamento per tenere conto della funzione raggruppata e della clausola SUM BY. ORDER L'operatore Sort iniziale viene eseguito in parallelo sui nodi di calcolo. Quindi l'operatore Network invia i risultati al nodo principale, dove l'operatore Merge produce i risultati finali ordinati.

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)

Ridistribuzione dei dati

L'EXPLAINoutput per i join specifica anche un metodo per lo spostamento dei dati all'interno di un cluster per facilitare l'unione. Questo movimento di dati può essere sia una trasmissione che una ridistribuzione. In una trasmissione, i valori dei dati da un lato della combinazione vengono copiati da ogni nodo di calcolo su ogni altro nodo di calcolo, così che ognuno di essi finisca con una copia completa dei dati. In una ridistribuzione, la partecipazione dei valori dei dati viene inviata dalla loro sezione attuale alla nuova sezione (possibilmente su un nodo differente). Solitamente i dati vengono ridistribuiti per far corrispondere la chiave di distribuzione dell'altra tabella che ha partecipato alla combinazione, nel caso in cui la chiave di distribuzione sia una delle colonne di combinazione. Se nessuna delle tabelle dispone di chiavi di distribuzione su una delle colonne di combinazione, entrambe le tabelle vengono distribuite o la tabella interna viene trasmessa a ogni nodo.

L'EXPLAINoutput fa riferimento anche a tabelle interne ed esterne. La tabella interna viene scansionata per prima e appare più vicina al fondo del piano di query. La tabella interna è la tabella in cui si trovano le corrispondenza. Questa si trova solitamente in memoria, di solito è la tabella di origine per l'hashing e, probabilmente, è la tabella più piccola delle due combinate. La tabella esterna è la sorgente delle righe da combinare con la tabella interna. Viene letta solitamente dal disco. L'ottimizzatore di query sceglie la tabella interna ed esterna in base alle statistiche del database relative all'ultima esecuzione del ANALYZE comando. L'ordine delle tabelle nella FROM clausola di una query non determina quale tabella è interna e quale è esterna.

Utilizza i seguenti attributi nei piani di query, per identificare come verranno spostati i dati per facilitare una query: