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.
# Analyse du résumé de la requête
Pour obtenir des statistiques et des étapes d’exécution plus détaillées que dans le plan de requête généré par [EXPLAIN](r_EXPLAIN.md), utilisez les vues système [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) et [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md).
SVL\$1QUERY\$1SUMMARY fournit des statistiques de requête par flux. Vous pouvez utiliser les informations fournies pour identifier les problèmes posés par les étapes onéreuses, de longue durée et qui écrivent sur le disque.
La vue système SVL\$1QUERY\$1REPORT vous permet de consulter des informations similaires à celles de SVL\$1QUERY\$1SUMMARY, uniquement par tranche de nœuds de calcul, et non par flux. Vous pouvez utiliser les informations au niveau de la tranche pour identifier la distribution inégale de données dans le cluster (également appelée asymétrie de la distribution de données), qui force certains nœuds à travailler davantage que d’autres et affecte les performances des requêtes.
**Topics**
+ [
# Utilisation de la vue SVL\$1QUERY\$1SUMMARY
](using-SVL-Query-Summary.md)
+ [
# Utilisation de la vue SVL\$1QUERY\$1REPORT
](using-SVL-Query-Report.md)
+ [
# Mappage du plan de requête au résumé de la requête
](query-plan-summary-map.md)
# Utilisation de la vue SVL\$1QUERY\$1SUMMARY
Pour analyser les informations récapitulatives sur la requête par flux à l’aide de [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md), procédez comme suit :
1. Exécutez la requête suivante pour déterminer l’ID de votre requête :
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Examinez le texte de la requête tronquée dans le champ `substring` pour déterminer quelle valeur de `query` représente votre requête. Si vous avez exécuté la requête plusieurs fois, utilisez la valeur de `query` de la ligne avec la valeur de `elapsed` inférieure. Il s’agit de la ligne de la version compilée. Si vous avez exécuté un grand nombre de requêtes, vous pouvez augmenter la valeur utilisée par la clause LIMIT utilisée pour vous assurer que votre requête est incluse.
1. Sélectionnez les lignes de SVL\$1QUERY\$1SUMMARY pour votre requête. Ordonnez les résultats par flux, par segment et par étape :
```
select * from svl_query_summary where query = MyQueryID order by stm, seg, step;
```
Voici un exemple de résultat.
![\[Exemple de résultat pour les lignes dans SVL_QUERY_SUMMARY correspondant à une requête donnée.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/svl_query_summary_results.png)
1. Mappe les étapes aux opérations du plan de requête à l’aide des informations de [Mappage du plan de requête au résumé de la requête](query-plan-summary-map.md). Elles doivent avoir à peu près les mêmes valeurs pour les lignes et les octets (lignes \$1 largeur dans le plan de requête). Si ce n’est pas le cas, consultez [Statistiques de table manquantes ou obsolètes](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date) pour connaître les solutions recommandées.
1. Vérifiez si le champ `is_diskbased` a une valeur de `t` (true) pour n’importe quelle étape. Les hachages, les agrégats et les tris sont les opérateurs susceptibles d’écrire des données sur le disque si le système ne dispose pas de suffisamment de mémoire allouée pour le traitement des requêtes.
Si `is_diskbased` a la valeur true, consultez [Mémoire insuffisante allouée à la requête](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query) pour connaître les solutions recommandées.
1. Passez en revue les valeurs des `label` champs et vérifiez s'il existe une AGG-DIST-AGG séquence quelconque dans les étapes. Sa présence indique une agrégation en deux étapes, ce qui est onéreux. Pour résoudre ce problème, modifiez la clause GROUP BY pour utiliser la clé de distribution (la première clé, s’il y en a plusieurs).
1. Vérifiez la valeur de `maxtime` de chaque segment (identique à toutes les étapes du segment). Identifiez le segment ayant la valeur de `maxtime` la plus élevée et vérifiez les étapes de ce segment pour les opérateurs suivants.
**Note**
Une valeur de `maxtime` élevée n’indique pas nécessairement de problème avec le segment. Malgré une valeur élevée, le temps de traitement du segment pourrait ne pas avoir été long. Tous les segments d’un flux sont chronométrés ensemble. Toutefois, certains segments en aval ne sont peut-être pas en mesure de s’exécuter tant qu’ils n’obtiennent pas de données de ceux situés en amont. Cela peut donner l’impression qu’ils ont pris beaucoup de temps, car leur valeur `maxtime` inclura leur temps d’attente et leur temps de traitement.
+ **BCAST ou DIST** : dans ces cas, la valeur de `maxtime` élevée peut être le résultat d’une redistribution d’un grand nombre de lignes. Pour connaître les solutions recommandées, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
+ **HJOIN (jointure par hachage)** : si l’étape en question a une valeur très élevée dans le champ `rows` par rapport à la valeur de `rows` dans l’étape RETURN finale dans la requête, consultez [Joindre par hachage](query-performance-improvement-opportunities.md#hash-join) pour connaître les solutions recommandées.
+ **SCAN/SORT** : recherchez une séquence d’étapes SCAN, SORT, SCAN, MERGE juste avant une étape de jointure. Ce modèle indique que des données non triées sont analysées, triées, puis fusionnées avec la région triée de la table.
Vérifiez si la valeur des lignes de l’étape SCAN est très élevée par rapport à la valeur des lignes de l’étape RETURN finale dans la requête. Ce modèle indique que le moteur d’exécution analyse des lignes qui sont ignorées par la suite, ce qui est inefficace. Pour connaître les solutions recommandées, consultez [Prédicat pas assez restrictif](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate).
Si la valeur `maxtime` de l’étape SCAN est élevée, consultez [Clause WHERE sous-optimale](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause) pour connaître les solutions recommandées.
Si la valeur `rows` de l’étape SORT n’est pas égale à zéro, consultez [Lignes non triées ou mal triées](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) pour connaître les solutions recommandées.
1. Vérifiez les valeurs `rows` et `bytes` des étapes 5 à 10 précédant l’étape RETURN finale pour savoir quelle est la quantité de données renvoyée au client. Ce processus peut être complexe.
Par exemple, dans l’exemple de requête récapitulative suivant, la troisième étape PROJECT fournit une valeur de `rows`, mais pas une valeur de `bytes`. Les étapes précédentes avec la même valeur de `rows` vous permettront de trouver l’étape SCAN qui fournit des informations sur les lignes et les octets :
Voici un exemple de résultat.
![\[Une ligne des résultats de la requête récapitulative correspond à une étape SCAN avec des informations à la fois sur les lignes et sur les octets.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/rows_and_bytes.png)
Si vous renvoyez un volume inhabituellement élevé de données, consultez [Ensemble de résultats très volumineux](query-performance-improvement-opportunities.md#very-large-result-set) pour connaître les solutions recommandées.
1. Vérifiez si la valeur de `bytes` est élevée par rapport à la valeur de `rows` pour n’importe quelle étape, par rapport aux autres étapes. Ce modèle peut indiquer que vous sélectionnez un grand nombre de colonnes. Pour connaître les solutions recommandées, consultez [Longue liste SELECT](query-performance-improvement-opportunities.md#large-SELECT-list).
# Utilisation de la vue SVL\$1QUERY\$1REPORT
Pour analyser les informations récapitulatives sur la requête par tranche à l’aide de [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md), procédez comme suit :
1. Exécutez la commande suivante pour déterminer l’ID de votre requête :
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Examinez le texte de la requête tronquée dans le champ `substring` pour déterminer quelle valeur de `query` représente votre requête. Si vous avez exécuté la requête plusieurs fois, utilisez la valeur de `query` de la ligne avec la valeur de `elapsed` inférieure. Il s’agit de la ligne de la version compilée. Si vous avez exécuté un grand nombre de requêtes, vous pouvez augmenter la valeur utilisée par la clause LIMIT utilisée pour vous assurer que votre requête est incluse.
1. Sélectionner des lignes dans SVL\$1QUERY\$1REPORT pour votre requête. Ordonnez les résultats par segment, par étape, par elapsed\$1time et par lignes :
```
select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows;
```
1. Pour chaque étape, vérifiez que toutes les tranches traitent à peut près le même nombre de lignes :
![\[Liste des tranches de données utilisées pour exécuter une requête. Chaque tranche traite approximativement le même nombre de lignes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)
Vérifiez également que toutes les tranches prennent à peu près autant de temps :
![\[Liste des tranches de données utilisées pour exécuter une requête. Chaque tranche prend approximativement le même temps.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png)
Si ces valeurs sont très différences, cela peut révéler une asymétrie de la distribution des données due à un style de distribution sous-optimal pour cette requête particulière. Pour connaître les solutions recommandées, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Mappage du plan de requête au résumé de la requête
Lors de l’analyse de la requête récapitulative, vous pouvez obtenir plus de détails en mappant les opérations entre le plan de la requête et les étapes (identifiées par les valeurs du champ d’étiquette) dans le résumé de la requête. La table suivante fait correspondre les opérations du plan de requête aux étapes de la requête récapitulative.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/query-plan-summary-map.html)