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. # Amélioration des performances des requêtes Voici quelques problèmes courants qui affectent les performances des requêtes Amazon Redshift, avec des instructions et des manières de les diagnostiquer et de les résoudre. **Topics** + [Statistiques de table manquantes ou obsolètes](#table-statistics-missing-or-out-of-date) + [Boucle imbriquée](#nested-loop) + [Joindre par hachage](#hash-join) + [Lignes fantômes ou non validées](#ghost-rows-or-uncommitted-rows) + [Lignes non triées ou mal triées](#unsorted-or-mis-sorted-rows) + [Distribution des données sous-optimales](#suboptimal-data-distribution) + [Mémoire insuffisante allouée à la requête](#insufficient-memory-allocated-to-the-query) + [Clause WHERE sous-optimale](#suboptimal-WHERE-clause) + [Prédicat pas assez restrictif](#insufficiently-restrictive-predicate) + [Ensemble de résultats très volumineux](#very-large-result-set) + [Longue liste SELECT](#large-SELECT-list) ## Statistiques de table manquantes ou obsolètes Si des statistiques de la table sont manquantes ou obsolètes, ce qui suit peut s’afficher : + Un message d’avertissement dans les résultats de la commande EXPLAIN. + Un événement d’alerte de statistiques manquantes dans STL\_ALERT\_EVENT\_LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md). Pour résoudre ce problème, exécutez [ANALYSE](r_ANALYZE.md). ## Boucle imbriquée Si une boucle imbriquée est présente, un événement d’alerte de boucle imbriquée peut s’afficher dans STL\_ALERT\_EVENT\_LOG. Vous pouvez également identifier ce type d’événement en exécutant la requête de la section [Identification des requêtes avec des boucles imbriquées](identify-queries-with-nested-loops.md). Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md). Pour résoudre ce problème, vérifiez s’il existe des jointures croisées dans votre requête et supprimez-les si possible. Les jointures croisées sont des jointures sans condition de jointure qui entraînent le produit cartésien de deux tables. Elles sont généralement exécutées en tant que jointures de boucle imbriquée, qui sont les types de jointures les plus lents possibles. ## Joindre par hachage Si une jointure par hachage est présente, les éléments suivants peuvent s’afficher : + Des opérations de hachage et de jointure par hachage dans le plan de la requête. Pour plus d’informations, consultez [Analyse du plan de requête](c-analyzing-the-query-plan.md). + Une étape HJOIN dans le segment avec la valeur maxtime la plus élevée dans SVL\_QUERY\_SUMMARY. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). Pour résoudre ce problème, vous pouvez adopter deux approches : + Réécrivez la requête afin d’utiliser une jointure par fusion si possible. Pour cela, spécifiez les colonnes de jointure qui sont des clés de distribution et des clés de tri. + Si l’étape HJOIN de SVL\_QUERY\_SUMMARY a une très grande valeur dans le champ des lignes par rapport à la valeur des lignes de l’étape RETURN finale de la requête, vérifiez si vous pouvez réécrire la requête afin d’effectuer une jointure avec une colonne unique. Lorsqu’une requête n’effectue pas de jointure avec une colonne unique, telle qu’une clé primaire, cela augmente le nombre de lignes impliquées dans la jointure. ## Lignes fantômes ou non validées Si des lignes fantômes ou non validées sont présentes, un événement d’alerte peut s’afficher dans STL\_ALERT\_EVENT\_LOG indiquant un nombre de lignes fantômes excessif. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md). Pour résoudre ce problème, vous pouvez adopter deux approches : + Vérifiez l’onglet **Charges** de votre console Amazon Redshift pour les opérations de charge actives sur l’une des tables de requête. Si vous voyez des opérations de chargement actives, attendez qu’elles se terminent avant d’agir. + S’il n’y a aucune opération de charge active, exécutez [VACUUM](r_VACUUM_command.md) sur les tables de la requête pour supprimer les lignes supprimées. ## Lignes non triées ou mal triées Si des lignes non triées ou mal triées sont présentes, un événement d’alerte de filtre très sélectif peut s’afficher dans STL\_ALERT\_EVENT\_LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md). Vous pouvez également vérifier si l’une des tables de votre requête présente de grandes zones non triés en exécutant la requête [Identification des tables comportant une asymétrie des données ou des lignes non triées](identify-tables-with-data-skew-or-unsorted-rows.md). Pour résoudre ce problème, vous pouvez adopter deux approches : + Exécutez [VACUUM](r_VACUUM_command.md) sur les tables de requête pour trier à nouveau les lignes. + Vérifiez les clés de tri des tables de la requête pour voir si des améliorations peuvent être apportées. N’oubliez pas de comparer les performances de cette requête par rapport aux performances d’autres requêtes importantes et au système global avant toute modification. Pour plus d’informations, consultez [Clés de tri](t_Sorting_data.md). ## Distribution des données sous-optimales Si la distribution des données est sous-optimale, les éléments suivants peuvent s’afficher : + Un événement d’alerte d’exécution en série, de grande diffusion ou de grande distribution s’affiche dans STL\_ALERT\_EVENT\_LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md). + Les tranches ne traitent pas le même nombre de lignes (approximativement) pour une étape donnée. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_REPORT](using-SVL-Query-Report.md). + Les tranches ne prennent pas autant de temps (approximativement) pour une étape donnée. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_REPORT](using-SVL-Query-Report.md). Si rien de ce qui précède ne s’applique, vous pouvez également vérifier si l’une des tables de votre requête comporte une asymétrie des données en exécutant la requête dans [Identification des tables comportant une asymétrie des données ou des lignes non triées](identify-tables-with-data-skew-or-unsorted-rows.md). Pour résoudre ce problème, vérifiez les styles de distribution des tables de la requête afin de voir si des améliorations peuvent être apportées. N’oubliez pas de comparer les performances de cette requête par rapport aux performances d’autres requêtes importantes et au système global avant toute modification. Pour plus d’informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md). ## Mémoire insuffisante allouée à la requête Si la mémoire allouée à votre requête est insuffisante, vous pouvez voir qu’une étape de SVL\_QUERY\_SUMMARY comporte une valeur true pour `is_diskbased`. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). Pour résoudre ce problème, allouez davantage de mémoire à la requête en augmentant temporairement le nombre d’emplacements de requête qu’elle utilise. La gestion de la charge de travail (WLM) réserve des emplacements dans une file d’attente de requête équivalents à au niveau de simultanéité défini pour la file d’attente. Par exemple, une file d’attente avec un niveau de simultanéité de 5 dispose de 5 emplacements. La mémoire affectée à la file d’attente est allouée à part égale à chaque emplacement. L’affectation de plusieurs emplacements à une requête donne à celle-ci accès à la mémoire de tous ces emplacements. Pour plus d’informations sur la procédure permettant d’augmenter temporairement les emplacements d’une requête, consultez [wlm\_query\_slot\_count](r_wlm_query_slot_count.md). ## Clause WHERE sous-optimale Si votre clause WHERE entraîne des analyses de tables excessives, une étape SCAN peut s’afficher dans le segment ayant la valeur de `maxtime` la plus élevée dans SVL\_QUERY\_SUMMARY. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). Pour résoudre ce problème, ajoutez une clause WHERE à la requête basée sur la colonne de tri primaire de la table la plus volumineuse. Cette approche permet de réduire le temps d’analyse. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de tables](c_designing-tables-best-practices.md). ## Prédicat pas assez restrictif Si votre requête a un prédicat qui n’est pas suffisamment restrictif, une étape SCAN peut s’afficher dans le segment avec la valeur de `maxtime` la plus élevée dans SVL\_QUERY\_SUMMARY avec une valeur de `rows` très importante par rapport à la valeur de `rows` de l’étape RETURN finale de la requête. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). Pour résoudre ce problème, essayez d’ajouter un prédicat à la requête ou de rendre le prédicat existant plus restrictifs pour affiner les données de sortie. ## Ensemble de résultats très volumineux Si votre requête renvoie un ensemble de résultats très volumineux, envisagez de réécrire la requête pour utiliser [UNLOAD](r_UNLOAD.md) afin d’écrire les résultats sur Amazon S3. Cette approche permettra d’améliorer les performances de l’étape RETURN en tirant parti du traitement parallèle. Pour plus d’informations sur la recherche d’un ensemble de résultats très volumineux, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). ## Longue liste SELECT Si votre requête comporte une liste SELECT inhabituellement longue, une valeur de `bytes` élevée peut s’afficher par rapport à la valeur de `rows` de n’importe quelle étape (comparée à d’autres étapes) dans SVL\_QUERY\_SUMMARY. Cette valeur de `bytes` élevée peut indiquer que vous sélectionnez un grand nombre de colonnes. Pour plus d’informations, consultez [Utilisation de la vue SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md). Pour résoudre ce problème, vérifiez les colonnes que vous sélectionnez pour voir si certaines peuvent être supprimées.