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
Vous trouverez ci-dessous quelques problèmes courants qui affectent les performances des requêtes Amazon Redshift, ainsi que des instructions sur les moyens de les diagnostiquer et de les résoudre.
Rubriques
- Statistiques de table manquantes ou obsolètes
- Boucle imbriquée
- Joindre par hachage
- Lignes fantômes ou non validées
- Lignes non triées ou mal triées
- Distribution des données sous-optimales
- Mémoire insuffisante allouée à la requête
- Clause sous-optimale WHERE
- Prédicat pas assez restrictif
- Ensemble de résultats très volumineux
- Grande SELECT liste
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 apparaît dans les résultats de la EXPLAIN commande.
-
Un événement d'alerte statistique manquant dans STL _ ALERT _ EVENT _LOG. Pour de plus amples informations, veuillez consulter Révision des alertes de requêtes.
Pour résoudre ce problème, exécutez ANALYZE.
Boucle imbriquée
Si une boucle imbriquée est présente, vous pouvez voir un événement d'alerte de boucle imbriquée 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. Pour de plus amples informations, veuillez consulter Révision des alertes de requêtes.
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 de plus amples informations, veuillez consulter Analyse du plan de requête.
-
HJOINÉtape du segment dont la valeur maxtime est la plus élevée en SVL _ QUERY _SUMMARY. Pour de plus amples informations, veuillez consulter Utilisation de la SUMMARY vue SVL QUERY _ _.
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'HJOINétape de SVL _ QUERY _ SUMMARY possède une valeur très élevée dans le champ des lignes par rapport à la valeur des lignes de la dernière RETURN étape de la requête, vérifiez si vous pouvez réécrire la requête pour la joindre à 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, vous pouvez voir un événement d'alerte dans STL _ _ ALERT EVENT _ LOG indiquant un nombre excessif de lignes fantômes. Pour de plus amples informations, veuillez consulter Révision des alertes de requêtes.
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 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, vous pouvez voir un événement d'alerte de filtrage très sélectif dans STL _ _ _ALERT. EVENT LOG Pour de plus amples informations, veuillez consulter Révision des alertes de requêtes.
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.
Pour résoudre ce problème, vous pouvez adopter deux approches :
-
Exécutez VACUUM 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 de plus amples informations, veuillez consulter Clés de tri.
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 diffusion importante ou de distribution importante apparaît dans STL _ ALERT _ EVENT _LOG. Pour de plus amples informations, veuillez consulter Révision des alertes de requêtes.
-
Les tranches ne traitent pas le même nombre de lignes (approximativement) pour une étape donnée. Pour de plus amples informations, veuillez consulter Utilisation de la REPORT vue SVL QUERY _ _.
-
Les tranches ne prennent pas autant de temps (approximativement) pour une étape donnée. Pour de plus amples informations, veuillez consulter Utilisation de la REPORT vue SVL QUERY _ _.
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.
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 de plus amples informations, veuillez consulter Distribution des données pour l'optimisation des requêtes.
Mémoire insuffisante allouée à la requête
Si la mémoire allouée à votre requête est insuffisante, il se peut SUMMARY que vous voyiez apparaître une étape dans SVL QUERY _ _ dont is_diskbased la valeur est true. Pour de plus amples informations, veuillez consulter Utilisation de la SUMMARY vue SVL QUERY _ _.
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. Workload Management (WLM) réserve des emplacements dans une file de requêtes é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.
Clause sous-optimale WHERE
Si votre WHERE clause entraîne des analyses de table excessives, il est possible que vous voyiez une SCAN étape dans le segment dont la maxtime valeur est la plus élevée dans SVL _ QUERY _SUMMARY. Pour de plus amples informations, veuillez consulter Utilisation de la SUMMARY vue SVL QUERY _ _.
Pour résoudre ce problème, ajoutez une WHERE clause à la requête en fonction de la colonne de tri principale de la plus grande table. Cette approche permet de réduire le temps d’analyse. Pour de plus amples informations, veuillez consulter Bonnes pratiques Amazon Redshift pour la conception de tables.
Prédicat pas assez restrictif
Si votre requête contient un prédicat insuffisamment restrictif, il se peut SUMMARY qu'une SCAN étape du segment présentant la maxtime valeur la plus élevée dans SVL _ QUERY _ présente une rows valeur très élevée par rapport à la rows valeur de la dernière RETURN étape de la requête. Pour de plus amples informations, veuillez consulter Utilisation de la SUMMARY vue SVL QUERY _ _.
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 afin d’écrire les résultats sur Amazon S3. Cette approche améliore les performances de l'RETURNétape 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 SUMMARY vue SVL QUERY _ _.
Grande SELECT liste
Si votre requête contient une SELECT liste anormalement longue, vous pouvez voir une bytes valeur élevée par rapport à la rows valeur de n'importe quelle étape (par rapport aux autres étapes) dans SVL _ QUERY _SUMMARY. Cette valeur de bytes élevée peut indiquer que vous sélectionnez un grand nombre de colonnes. Pour de plus amples informations, veuillez consulter Utilisation de la SUMMARY vue SVL QUERY _ _.
Pour résoudre ce problème, vérifiez les colonnes que vous sélectionnez pour voir si certaines peuvent être supprimées.
