Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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](c-query-analysis-process.md). ## Syntaxe ``` EXPLAIN [ VERBOSE ] query ``` ## Parameters 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 instruction SELECT, INSERT, CREATE TABLE AS, UPDATE ou DELETE. ## Notes d’utilisation Les performances d’EXPLAIN sont parfois influencées par le temps nécessaire à la création de tables temporaires. Par exemple, une requête qui utilise l’optimisation courante des sous-expressions nécessite la création et l’analyse de tables temporaires pour renvoyer la sortie EXPLAIN. Le plan de requête dépend du schéma et des statistiques des tables temporaires. Par conséquent, la commande EXPLAIN pour ce type de requête peut prendre plus de temps pour s’exécuter que prévu. Vous pouvez utiliser EXPLAIN uniquement pour les commandes suivantes : + SELECT + SELECT INTO + CREATE TABLE AS + INSERT + UPDATE + DELETE La commande EXPLAIN échoue si vous l’utilisez pour d’autres commandes SQL, telles que le langage de définition de données (DDL) ou les opérations de base de données. Les coûts unitaires relatifs de sortie EXPLAIN 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](c-query-processing.md). 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. [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_EXPLAIN.html) ## Utilisation d’EXPLAIN pour RLS Si une requête contient une table soumise à des politiques de sécurité au niveau des lignes (RLS), EXPLAIN affiche un nœud RLS spécial. SecureScan Amazon Redshift enregistre également le même type de nœud dans la table système STL\_EXPLAIN. EXPLAIN ne révèle pas le prédicat RLS qui s’applique à dim\_tbl. Le type de SecureScan nœud RLS indique que le plan d'exécution contient des opérations supplémentaires invisibles pour l'utilisateur actuel. L'exemple suivant illustre un SecureScan nœud RLS. ``` 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 enquête complète des plans de requêtes soumis au RLS, Amazon Redshift propose les autorisations système EXPLAIN RLS. Les utilisateurs auxquels cette autorisation a été accordée peuvent inspecter des plans de requêtes complets qui comprennent également des prédicats RLS. L'exemple suivant illustre un Seq Scan supplémentaire situé sous le SecureScan nœud RLS et inclut également le prédicat de politique RLS (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’autorisation EXPLAIN RLS est accordée à un utilisateur, Amazon Redshift enregistre le plan de requêtes complet, y compris les prédicats RLS dans la table système STL\_EXPLAIN. Les requêtes qui sont exécutées alors que cette autorisation n’est pas accordée seront enregistrées sans les données internes RLS. Accorder ou supprimer l’autorisation EXPLAIN RLS ne changera pas ce qu’Amazon Redshift a enregistré dans STL\_EXPLAIN pour les requêtes précédentes. ### Relations Redshift protégées par AWS Lake Formation-RLS L'exemple suivant illustre un SecureScan nœud LF, que vous pouvez utiliser pour visualiser les relations Lake Formation-RLS. ``` 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 EVENTID, EVENTNAME, VENUEID et VENUENAME à partir des tables EVENT et VENUE : ``` 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) ```