Best practice per la progettazione di query Amazon Redshift

Questa sezione fornisce una panoramica delle migliori pratiche per la progettazione di query. Si consiglia di seguire le best practice riportate in questa sezione per ottenere prestazioni ed efficienza ottimali delle query.

Evitare di utilizzare l'istruzione SELECT * FROM

Si consiglia di evitare l'uso dell'SELECT * FROMistruzione. Invece, elenca sempre le colonne per l'analisi. Ciò riduce i tempi di esecuzione delle query e i costi di scansione per le query Amazon Redshift Spectrum.

Esempio di cosa evitare

select * 
from sales;

Esempio di buona pratica

select sales_date, sales_amt
from sales;

Identifica i problemi relativi alle query

Ti consigliamo di controllare la vista STL_ALERT_EVENT_LOG per identificare e correggere possibili problemi relativi alla tua query.

Ottieni informazioni di riepilogo sulla tua richiesta

Ti consigliamo di utilizzare le viste SVL_QUERY_SUMMARY e SVL_QUERY_REPORT per ottenere informazioni di riepilogo sulle tue domande. È possibile utilizzare queste informazioni per ottimizzare le query.

Evita le giunzioni incrociate

Ti consigliamo di evitare di utilizzare i cross-join a meno che non sia assolutamente necessario. Senza una condizione di unione, i cross-join danno come risultato il prodotto cartesiano di due tabelle. I cross-join vengono in genere eseguiti come join a loop annidato (i tipi di join più lenti possibili).

Esempio di cosa evitare

select c.c_name, 
          n.n_name 
from tpch.customer c, 
        tpch.nation n;

Esempio di buona pratica

select c.c_name, 
           n.n_name 
from tpch.customer c, 
join tpch.nation n
  on n.n_nationkey = c.c_nationkey;

Evita le funzioni nei predicati di interrogazione

Si consiglia di evitare l'uso di funzioni nei predicati di interrogazione. L'utilizzo di funzioni nei predicati di query può influire negativamente sulle prestazioni perché le funzioni in genere aggiungono un sovraccarico di elaborazione aggiuntivo a ciascuna riga e rallentano l'esecuzione complessiva della query.

Esempio di cosa evitare

select sum(o_totalprice)
from tpch.orders
where datepart(year, o_orderdate) = 1992;

Esempio di buona pratica

select sum(o_totalprice)
from tpch.orders
where o_orderdate between '1992-01-01' and '1992-12-31';

Evita conversioni di cast non necessarie

Si consiglia di evitare di utilizzare conversioni cast non necessarie sulle query, poiché il casting dei tipi di dati richiede tempo e risorse e rallenta l'esecuzione delle query.

Esempio di cosa evitare

select sum(o_totalprice)
from tpch.orders
where o_ordertime::date = '1992-01-01';

Esempio di buona pratica

select sum(o_totalprice)
from tpch.orders
where o_ordertime between '1992-01-01 00:00:00' and '1992-12-31 23:59:59';

Usa le espressioni CASE per aggregazioni complesse

Si consiglia di utilizzare un'espressione CASE per eseguire aggregazioni complesse anziché effettuare più selezioni dalla stessa tabella.

Esempio di cosa evitare

select sum(sales_amt) as us_sales
from sales
where country = 'US';

select sum(sales_amt) as ca_sales
from sales
where country = 'CA';

Esempio di buona pratica

select sum(case when country = 'US' then sales_amt end) as us_sales,
           sum(case when country = 'CA' then sales_amt end) as ca_sales
from sales;

Usa le sottoquery

È consigliabile utilizzare le sottoquery nei casi in cui una tabella della query viene utilizzata solo per le condizioni dei predicati e la sottoquery restituisce un numero limitato di righe (meno di 200 circa).

Esempio di cosa evitare

Se una sottoquery restituisce meno di 200 righe:

select sum(order_amt) as total_sales
from sales
where region_key IN
        (select region_key
         from regions
         where state = 'CA');

Esempio di best practice

Se una sottoquery restituisce un valore maggiore o uguale a 200 righe:

select sum(o.order_amt) as total_sales
from sales o
join regions r
  on r.region_key = o.region_key
  and r.state = 'CA';

Usa i predicati

Ti consigliamo di utilizzare i predicati per limitare il più possibile il set di dati. I predicati vengono utilizzati in SQL per filtrare e limitare i dati restituiti in una query. Specificando le condizioni in un predicato, è possibile specificare quali righe devono essere incluse nei risultati della query in base a condizioni specificate. In questo modo puoi recuperare solo i dati che ti interessano e migliora l'efficienza e la precisione delle tue query. Per ulteriori informazioni, consulta le Condizioni nella documentazione di Amazon Redshift.

Aggiungi predicati per filtrare le tabelle con join

Ti consigliamo di aggiungere i predicati alle tabelle di filtri che partecipano ai join, anche se i predicati applicano gli stessi filtri. L'utilizzo dei predicati per filtrare le tabelle con join in SQL può migliorare le prestazioni delle query riducendo la quantità di dati da elaborare e riducendo la dimensione del set di risultati intermedio. Specificando le condizioni per l'operazione di join nella WHERE clausola, il motore di esecuzione delle query può eliminare le righe che non soddisfano le condizioni prima che vengano unite. Ciò si traduce in un set di risultati più piccolo e un'esecuzione delle query più rapida.

Esempio di cosa evitare

select p.product_name, sum(o.order_amt)
from sales o
join product p
   on r.product_key = o.product_key
where o.order_date > '2022-01-01';

Esempio di buona pratica

select p.product_name, sum(o.order_amt)
from sales o
join product p
  on p.product_key = o.product_key
  and p.added_date > '2022-01-01'
where o.order_date > '2022-01-01';

Utilizzate gli operatori meno costosi per i predicati

Nel predicato, utilizzate gli operatori meno costosi che potete. Gli operatori delle condizioni di confronto sono preferibili agli operatori LIKE. LIKEgli operatori sono ancora preferibili agli operatori SIMILAR TO o POSIX.

Utilizza le chiavi di ordinamento nelle clausole GROUP BY

Utilizza le chiavi di ordinamento nella GROUP BY clausola in modo che il pianificatore di query possa utilizzare un'aggregazione più efficiente. Una query può essere idonea per l'aggregazione monofase quando il relativo GROUP BY elenco contiene solo colonne chiave di ordinamento, una delle quali è anche la chiave di distribuzione. Le colonne delle chiavi di ordinamento dell'GROUP BYelenco devono includere la prima chiave di ordinamento, seguita da altre chiavi di ordinamento che si desidera utilizzare nell'ordine delle chiavi di ordinamento.

Sfrutta i vantaggi delle viste materializzate

Se possibile, riscrivi la query sostituendo il codice complesso con una vista materializzata, che migliorerà in modo significativo le prestazioni della query. Per ulteriori informazioni, consulta Creazione di viste materializzate in Amazon Redshift nella documentazione di Amazon Redshift.

Fai attenzione alle colonne nelle clausole GROUP BY e ORDER BY

Se utilizzi entrambe GROUP BY le ORDER BY clausole, assicurati di inserire le colonne nello stesso ordine in entrambe le clausole. GROUP BY ORDER BY GROUP BYrichiede implicitamente l'ordinamento dei dati. Se la ORDER BY clausola è diversa, i dati devono essere ordinati due volte.

Esempio di cosa evitare

select a, b, c, sum(d)
from a_table
group by b, c, a
order by a, b, c

Esempio di buona pratica

select a, b, c, sum(d)
from a_table
group by a, b, c
order by a, b, c