EXPLAIN - Amazon Redshift

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.

EXPLAIN

Affiche le plan d’exécution d’une instruction de requête sans exécution de la requête. Pour plus d’informations sur le flux de travail d’analyse des requêtes, consultez Flux de travail d’analyse des requêtes.

Syntaxe

EXPLAIN [ VERBOSE ] query

Paramètres

VERBOSE

Affiche le plan de requête complet au lieu d’un simple résumé.

query

Instruction de la requête à expliquer. La requête peut être une DELETE instruction SELECT INSERTUPDATE, CREATE TABLE AS ou.

Notes d’utilisation

EXPLAINles performances sont parfois influencées par le temps nécessaire pour créer des tables temporaires. Par exemple, une requête qui utilise l'optimisation des sous-expressions communes nécessite la création et l'analyse de tables temporaires afin de renvoyer le EXPLAIN résultat. Le plan de requête dépend du schéma et des statistiques des tables temporaires. Par conséquent, l'exécution de la EXPLAIN commande pour ce type de requête peut prendre plus de temps que prévu.

Vous ne pouvez les utiliser EXPLAIN que pour les commandes suivantes :

  • SELECT

  • SELECT INTO

  • CREATETABLEEN TANT QUE

  • INSERT

  • UPDATE

  • DELETE

La EXPLAIN commande échouera si vous l'utilisez pour d'autres SQL commandes, telles que le langage de définition des données (DDL) ou les opérations de base de données.

Les coûts unitaires relatifs en EXPLAIN sortie sont utilisés par Amazon Redshift pour choisir un plan de requête. Amazon Redshift compare les tailles de différentes estimations de ressources pour déterminer le plan.

Étapes de planification et d’exécution de la requête

Le plan d’exécution d’une instruction de requête Amazon Redshift spécifique ventile l’exécution et le calcul d’une requête en une séquence discrète d’étapes et d’opérations de table qui produisent un ensemble de résultats final pour la requête. Pour obtenir des informations sur la planification des requêtes, consultez Traitement des requêtes.

Le tableau suivant fournit un résumé des étapes qu’Amazon Redshift peut utiliser dans le développement d’un plan d’exécution dans le cas d’une requête qu’un utilisateur soumet pour l’exécution.

EXPLAINopérateurs Étapes de l’exécution d’une requête Description
SCAN:
Analyse séquentielle scan Opérateur ou étape d’analyse de table ou d’analyse de relation Amazon Redshift. Analyse l'ensemble de la table de manière séquentielle du début à la fin ; évalue également les contraintes de requête pour chaque ligne (filtre) si cela est spécifié avec une WHERE clause. Également utilisé pour exécuter INSERT des DELETE instructionsUPDATE, et.
JOINS: Amazon Redshift utilise différents 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 attributs spécifiques de la requête elle-même. Analyse des sous-requêtes : l'analyse et l'ajout de sous-requêtes sont utilisés pour exécuter des requêtes. UNION
Boucle imbriquée nloop Jointure la moins optimale ; principalement utilisée pour les jointures croisées (produits cartésiens, sans condition de jointure) et certaines jointures d’inégalité.
Joindre par hachage hjoin Également utilisé pour les jointures internes et les jointures externes gauche et droite, et généralement plus rapide qu’une jointure de boucle imbriquée. La jointure de hachage lit la table externe, hache la colonne de jointure et recherche les correspondances de la table de hachage interne. L’étape peut déverser sur le disque. (L’entrée interne de hjoin est une étape de hachage qui peut être basée sur le disque.)
Joindre par fusion mjoin Également utilisé pour les jointures internes et les jointures externes (pour les tables de jointure qui sont distribuées et triées sur les colonnes de jointure). Généralement, l’algorithme de jointure Amazon Redshift le plus rapide, sans inclure d’autres considérations de coût.
AGGREGATION: Opérateurs et étapes utilisés pour les requêtes impliquant des fonctions d'agrégation et des opérations GROUP BY.
Regrouper aggr Opérateur/étape pour les fonctions d’agrégation scalaires.
HashAggregate aggr Opérateur/étape pour les fonctions d’agrégation groupées. Peut fonctionner à partir du disque en raison du déversement de la table de hachage sur le disque.
GroupAggregate aggr Opérateur parfois choisi pour les requêtes agrégation groupées si le paramètre de configuration Amazon Redshift pour le paramètre force_hash_grouping est désactivé.
SORT: Opérateurs et étapes utilisés lorsque les requêtes doivent trier ou fusionner des ensembles de résultats.
Tri sort Le tri effectue le tri spécifié par la clause ORDER BY ainsi que d'autres opérations telles que UNIONs les jointures. Peut fonctionner à partir du disque.
Fusionner merge Produit les résultats finaux triés d’une requête basée sur les résultats intermédiaires triés provenant d’opérations effectuées en parallèle.
EXCEPTINTERSECT, et UNION opérations :
SetOp Sauf [Distinct] hjoin Utilisé pour les EXCEPT requêtes. Peut fonctionner à partir du disque en fonction du fait que l’entrée de hachage peut être basée sur le disque.
Hash Intersect [Distinct] hjoin Utilisé pour les INTERSECT requêtes. Peut fonctionner à partir du disque en fonction du fait que l’entrée de hachage peut être basée sur le disque.
Append [All |Distinct] enregistrer Ajout utilisé avec Subquery Scan pour implémenter UNION et UNION ALL interroger. Peut fonctionner à partir du disque grâce à « save ».
Divers/autres :
Hachage hachage Utilisé pour les jointures internes et les jointures externes gauche et droite (fournit une entrée à une jointure de hachage). L’opérateur de hachage crée la table de hachage pour la table interne d’une jointure. (La table interne est celle dans laquelle les correspondances sont vérifiées et, dans une jointure de deux tables, elle est généralement la plus petite des deux.)
Limite limite Évalue la LIMIT clause.
Materialize enregistrer Matérialise les lignes pour l’entrée des jointures de boucles imbriquées et quelques autres jointures de fusion. Peut fonctionner à partir du disque.
-- parse Utilisé pour analyser les données d’entrée texte pendant un chargement.
-- project Permet de réorganiser les colonnes et les expressions de calcul, à savoir les données du projet.
Résultat -- Exécute les fonctions scalaires qui n’impliquent pas un accès aux tables.
-- return renvoie les lignes au principal ou au client.
Subplan -- Utilisé pour certaines sous-requêtes.
Unique unique Élimine les doublons SELECT DISTINCT et les requêtes. UNION
Fenêtre window Fonctions d’agrégation de calcul et de fenêtrage de classement. Peut fonctionner à partir du disque.
Opérations de réseau :
Network (Broadcast) bcast Broadcast est également un attribut des opérateurs et des étapes Join Explain.
Network (Distribute) dist Distribue les lignes sur les nœuds de calcul pour le traitement parallèle par cluster d’entrepôt des données.
Network (Send to Leader) return Renvoie les résultats vers le principal en vue d’un traitement ultérieur.
DMLOpérations (opérateurs qui modifient les données) :
Insert (using Result) insert Insère les données.
Delete (Scan + Filter) supprimer Supprime les données. Peut fonctionner à partir du disque.
Update (Scan + Filter) delete, insert Implémenté comme Delete et Insert.

En utilisant EXPLAIN pour RLS

Si une requête contient une table soumise à des politiques de sécurité (RLS) au niveau des lignes, EXPLAIN affiche un nœud spécial RLS SecureScan . Amazon Redshift enregistre également le même type de nœud dans la table EXPLAIN système STL _. EXPLAINne révèle pas le RLS prédicat qui s'applique à dim_tbl. Le type de RLS SecureScan nœud indique que le plan d'exécution contient des opérations supplémentaires invisibles pour l'utilisateur actuel.

L'exemple suivant illustre un RLS SecureScan nœud.

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)

Pour permettre une analyse complète des plans de requêtes auxquels ils sont soumisRLS, Amazon Redshift fournit les autorisations EXPLAIN RLS système. Les utilisateurs qui ont obtenu cette autorisation peuvent inspecter les plans de requête complets qui incluent également des RLS prédicats.

L'exemple suivant illustre un Seq Scan supplémentaire situé sous le RLS SecureScan nœud et inclut également le prédicat de RLS politique (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)

Lorsque l'EXPLAINRLSautorisation est accordée à un utilisateur, Amazon Redshift enregistre le plan de requête complet, y compris RLS les prédicats dans la table système STL _EXPLAIN. Les requêtes exécutées alors que cette autorisation n'est pas accordée seront enregistrées sans données RLS internes. L'octroi ou la suppression de l'EXPLAINRLSautorisation ne modifiera pas le nom sur lequel Amazon Redshift s'est connecté à STL _ EXPLAIN pour les requêtes précédentes.

AWS Lake Formation- RLS relations Redshift protégées

L'exemple suivant illustre un SecureScan nœud LF, que vous pouvez utiliser pour visualiser les RLS relations entre Lake Formation et Formation.

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)

Exemples

Note

Pour ces exemples, l’exemple de sortie peut varier selon la configuration d’Amazon Redshift.

L'exemple suivant renvoie le plan de requête pour une requête qui sélectionne les tablesEVENTID,EVENTNAME,VENUEID, et VENUENAME à partir des VENUE tables EVENT et :

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’exemple suivant renvoie le plan de requête pour la même requête avec la sortie des commentaires :

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'exemple suivant renvoie le plan de requête pour une instruction 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)