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

Miglioramento delle prestazioni delle query

Di seguito sono riportati alcuni problemi comuni che influiscono sulle prestazioni delle query di Amazon Redshift, con istruzioni su come diagnosticarli e risolverli.

Statistiche della tabella mancanti o scadute

Se le statistiche della tabella sono mancanti o scadute, potresti visualizzare quanto segue:

Per risolvere questo problema, esegui il comando ANALYZE.

Loop nidificato

Se è presente un ciclo nidificato, è possibile che venga visualizzato un evento di avviso a ciclo annidato in STL _ _ ALERT _EVENT. LOG Per identificare questo tipo di evento, puoi anche eseguire la query su Identificazione di query con loop nidificati. Per ulteriori informazioni, consultare Revisione degli avvisi di query.

Per risolvere questo problema, rivedi la tua query per le combinazioni incrociate e rimuovile se possibile. Le combinazioni incrociate sono combinazione senza una condizione di combinazione nel prodotto cartesiano delle due tabelle. Generalmente vengono eseguite come combinazioni di loop nidificati, che sono le più lente tra i tipi di combinazione possibili.

Hash join

Se è presente un hash join, potresti visualizzare quanto segue:

Il problema può essere risolto in diversi modi:

Righe fantasma o righe di cui non è stato eseguito il commit

Se sono presenti righe fantasma o righe non impegnate, è possibile che venga visualizzato un evento di avviso in STL _ _ ALERT EVENT _ LOG che indica un numero eccessivo di righe fantasma. Per ulteriori informazioni, consulta Revisione degli avvisi di query.

Il problema può essere risolto in diversi modi:

Righe non ordinate o ordinate in modo errato

Se sono presenti righe non ordinate o ordinate male, è possibile che venga visualizzato un evento di avviso di filtro molto selettivo in _ _ _. STL ALERT EVENT LOG Per ulteriori informazioni, consulta Revisione degli avvisi di query.

Inoltre, puoi verificare la presenza di grandi aree non ordinate nelle tabelle della tua query, eseguendo la stessa su Identificazione delle tabelle con differenza di dati o con righe non ordinate.

Il problema può essere risolto in diversi modi:

Distribuzione dei dati non ottimale

Se la distribuzione dei dati non è ottimale, potresti visualizzare quanto segue:

Se nessuna delle opzioni precedenti è vera, puoi anche verificare se qualche tabella nella tua query presenta una differenza di dati, eseguendo la stessa su Identificazione delle tabelle con differenza di dati o con righe non ordinate.

Per risolvere questo problema, esamina gli stili di distribuzione delle tabelle nella query e determina se è possibile apportare dei miglioramenti. Ricordati di comparare le prestazioni di questa query a quelle di altre query importanti e al sistema globale prima di apportare delle modifiche. Per ulteriori informazioni, consultare Distribuzione dei dati per l'ottimizzazione delle query.

Memoria insufficiente allocata alla query

Se alla query non viene assegnata memoria sufficiente, è possibile SUMMARY che venga visualizzato un passaggio in SVL QUERY _ _ con is_diskbased il valore true. Per ulteriori informazioni, consulta Utilizzo della vista SVL _ _ QUERY SUMMARY.

Per risolvere il problema, alloca più memoria alla query aumentando temporaneamente il numero di slot che utilizza la query. Workload Management (WLM) riserva degli slot in una coda di interrogazioni equivalente al livello di concorrenza impostato per la coda. Ad esempio, una coda con un livello di simultaneità pari a 5, dispone di 5 slot. La memoria assegnata alla coda viene allocata in parti uguali a ogni slot. L'assegnazione di più slot per una query, le fornisce l'accesso alla memoria di tutti questi slot. Per ulteriori informazioni su come incrementare temporaneamente gli slot di una query, consultare wlm_query_slot_count.

WHEREClausola non ottimale

Se la WHERE clausola causa un numero eccessivo di scansioni della tabella, è possibile che venga visualizzato un SCAN passaggio nel segmento con il maxtime valore più alto in _ _. SVL QUERY SUMMARY Per ulteriori informazioni, consulta Utilizzo della vista SVL _ _ QUERY SUMMARY.

Per risolvere questo problema, aggiungi una WHERE clausola alla query basata sulla colonna di ordinamento principale della tabella più grande. Grazie a questo approccio, è possibile ridurre al minimo i tempi di scansione. Per ulteriori informazioni, consultare Best practice di Amazon Redshift per la progettazione di tabelle.

Predicato poco restrittivo

Se la query contiene un predicato non sufficientemente restrittivo, è possibile che venga visualizzato un SCAN passaggio nel segmento con il maxtime valore più alto in SVL _ QUERY _ SUMMARY che presenta un rows valore molto elevato rispetto al rows valore dell'ultimo RETURN passaggio della query. Per ulteriori informazioni, consulta Utilizzo della vista SVL _ _ QUERY SUMMARY.

Per risolvere questo problema. prova ad aggiungere un predicato alla query, oppure rendi il predicato esistente più restrittivo per restringere l'output.

Insieme di risultati molto grande

Se la query restituisce un set di risultati molto ampio, considerare la riscrittura della query per utilizzare UNLOAD e scrivere i risultati in Amazon S3. Questo approccio migliora le prestazioni della RETURN fase sfruttando l'elaborazione parallela. Per ulteriori informazioni sulla verifica di un insieme di risultati molto grande, consultare Utilizzo della vista SVL _ _ QUERY SUMMARY.

SELECTElenco ampio

Se la query contiene un SELECT elenco insolitamente grande, è possibile che venga visualizzato un bytes valore elevato rispetto al rows valore di ogni passaggio (rispetto agli altri passaggi) in SVL _ QUERY _SUMMARY. Questo valore bytes alto può indicare che stai selezionando molte colonne. Per ulteriori informazioni, consultare Utilizzo della vista SVL _ _ QUERY SUMMARY.

Per risolvere questo problema, rivedi le colonne che stai selezionando e verifica se puoi rimuoverne qualcuna.