Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Création et interprétation d'un plan de requêtes

Vous pouvez utiliser le plan de requête pour obtenir des informations sur les opérations individuelles requises pour exécuter une requête. Avant de travailler avec un plan de requête, nous vous recommandons de comprendre d’abord comment Amazon Redshift gère le traitement des requêtes et la création des plans de requête. Pour de plus amples informations, veuillez consulter Workflow d’exécution et de planification de requête.

Pour créer un plan de requête, exécutez la commande EXPLAIN suivie du texte de la requête réelle. Le plan de requête vous fournit les informations suivantes :

La EXPLAIN commande n'exécute pas réellement la requête. Elle montre seulement le plan que Amazon Redshift exécutera si la requête est exécutée dans les conditions d’utilisation actuelles. Si vous modifiez le schéma ou les données d’une table et que vous exécutez ANALYZE à nouveau pour mettre à jour les métadonnées statistiques, le plan de requête peut être différent.

Le plan de requête produit par EXPLAIN est une vue simplifiée de haut niveau de l'exécution des requêtes. Il n’illustre pas les détails du traitement de requête parallèle. Pour afficher des informations détaillées, exécutez la requête elle-même, puis obtenez les informations récapitulatives de la requête à partir de la REPORT vue SVL QUERY _ SVL _ SUMMARY ou QUERY _ _. Pour plus d’informations sur l’utilisation de ces vues, consultez Analyse du résumé de la requête.

L'exemple suivant montre le EXPLAIN résultat d'une simple requête GROUP BY sur la EVENT table :

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)

EXPLAINrenvoie les métriques suivantes pour chaque opération :

EXPLAINopérateurs

Cette section décrit brièvement les opérateurs que vous voyez le plus souvent dans la EXPLAIN sortie. Pour une liste complète des opérateurs, voir EXPLAIN la section SQL Commandes.

Opérateur d’analyse séquentielle

L’opérateur d’analyse séquentiel (Seq Scan) indique une analyse de table. Seq Scan analyse chaque colonne de la table de manière séquentielle du début à la fin et évalue les contraintes de requête (dans la WHERE clause) pour chaque ligne.

Opérateurs de jointure

Amazon Redshift sélectionne les opérateurs de jointure en fonction de la conception physique des tables jointes, de l’emplacement des données requises pour la jointure et des exigences spécifiques à la requête elle-même.

Opérateurs d’agrégation

Le plan de requête utilise les opérateurs suivants dans les requêtes impliquant des fonctions d'agrégation et des opérations GROUP BY.

Opérateurs de tri

Le plan de requête utilise les opérateurs suivants lorsque les requêtes doivent trier ou fusionner des jeux de résultats.

UNIONINTERSECT, et EXCEPT opérateurs

Le plan de requête utilise les opérateurs suivants pour les requêtes impliquant des opérations définies avec UNIONINTERSECT, etEXCEPT.

Autres opérateurs

Les opérateurs suivants apparaissent également fréquemment en EXPLAIN sortie pour les requêtes de routine.

Se joint à nous EXPLAIN

L’optimiseur de requête utilise différents types de jointures pour récupérer les données de la table, en fonction de la structure de la requête et des tables sous-jacentes. La EXPLAIN sortie fait référence au type de jointure, aux tables utilisées et à la manière dont les données des tables sont distribuées dans le cluster pour décrire le traitement de la requête.

Exemples de types de jointures

Les exemples suivants illustrent les différents types de jointures que l’optimiseur de requête peut utiliser. Le type de jointure utilisé dans le plan de requête dépend de la conception physique des tables impliquées.

Exemple : Joindre par hachage deux tables

La requête suivante joint EVENT et figure CATEGORY sur la CATID colonne. CATIDest la clé de distribution et de tri pourCATEGORY, mais pas pourEVENT. Une jointure par hachage est effectuée en EVENT tant que table extérieure et CATEGORY en tant que table intérieure. Comme il CATEGORY s'agit de la plus petite table, le planificateur en diffuse une copie aux nœuds de calcul pendant le traitement des requêtes à l'aide de DS_ BCAST _INNER. Le coût de la jointure de cet exemple représente la majeure partie du coût cumulé du plan.

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)

Exemple : Joindre par fusion deux tables

La requête suivante utilise également SELECT *, mais elle joint SALES et LISTING sur la LISTID colonne, où elle LISTID a été définie à la fois comme clé de distribution et comme clé de tri pour les deux tables. Une jointure par fusion est choisie, et aucune redistribution de données n'est requise pour la jointure (DS_ DIST _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’exemple suivant illustre les différents types de jointures au sein de la même requête. Comme dans l'exemple précédent, SALES et LISTING sont jointes par fusion, mais la troisième table doit être jointe par hachage avec les résultats de la jointure par fusion. EVENT Une fois encore, la jointure par hachage implique un coût de diffusion.

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)

Exemple : Joindre, regrouper et trier

La requête suivante exécute une jointure par hachage des EVENT tables SALES et, suivie d'opérations d'agrégation et de tri pour prendre en compte la SUM fonction groupée et la clause ORDER BY. L’opérateur Sort initial s’exécute en parallèle sur les nœuds de calcul. Puis, l’opérateur Network envoie les résultats au nœud principal, dans lequel l’opérateur Merge produit les résultats triés finaux.

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)

Redistribution des données

La EXPLAIN sortie pour les jointures spécifie également une méthode de déplacement des données dans un cluster afin de faciliter la jointure. Ce mouvement des données peut être une diffusion ou une redistribution. Dans une diffusion, les valeurs de données d’un côté d’une jointure sont copiées à partir de chaque nœud de calcul dans tous les autres nœuds de calcul, afin que chaque nœud de calcul se retrouve avec une copie complète des données. Dans une redistribution, les valeurs de données participantes sont envoyés de leur tranche actuelle vers une nouvelle tranche (éventuellement sur un autre nœud). Les données sont généralement redistribuées pour correspondre à la clé de distribution de l’autre table participant à la jointure si cette clé de distribution est l’une des colonnes de jointure. Si aucune des tables ne dispose de clés de distribution sur l’une des tables de jointure, les deux tables sont distribuées ou la table interne est diffusée à chaque nœud.

La EXPLAIN sortie fait également référence aux tables internes et externes. La table interne est analysée d’abord et s’affiche près de bas du plan de requête. La table interne est la table qui fait l’objet d’une recherche de correspondances. Elle est généralement conservée en mémoire, est généralement la table source pour le hachage et, si possible, est la plus petite des deux tables qui sont jointes. La table externe est la source des lignes à mettre en correspondant avec la table interne. Elle est généralement lue à partir du disque. L'optimiseur de requêtes choisit la table interne et externe en fonction des statistiques de base de données issues de la dernière exécution de la ANALYZE commande. L'ordre des tables dans la FROM clause d'une requête ne détermine pas quelle table est interne et laquelle est externe.

Utilisez les attributs suivants dans les plans de requête pour identifier la manière dont les données sont déplacées afin de simplifier une requête :