Amélioration des performances des requêtes

Voici quelques problèmes courants qui affectent les performances des requêtes, avec des instructions et des manières de les diagnostiquer et de les résoudre.

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 de plus amples informations, veuillez consulter Révision des alertes de requêtes.

Pour résoudre ce problème, exécutez ANALYSE.

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. 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.

• Une étape HJOIN dans le segment avec la valeur maxtime la plus élevée dans SVL_QUERY_SUMMARY. Pour de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_SUMMARY.

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 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, un événement d’alerte de filtre très sélectif peut s’afficher 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 Utilisation des 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 grande diffusion ou de grande distribution s’affiche 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 vue SVL_QUERY_REPORT.

• Les tranches ne prennent pas autant de temps (approximativement) pour une étape donnée. Pour de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_REPORT.

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 Utilisation des styles de distribution de données.

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 de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_SUMMARY.

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.

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 de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_SUMMARY.

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 de plus amples informations, veuillez consulter Bonnes pratiques Amazon Redshift pour la conception de tables.

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 de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_SUMMARY.

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 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.

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 de plus amples informations, veuillez consulter Utilisation de la vue SVL_QUERY_SUMMARY.

Pour résoudre ce problème, vérifiez les colonnes que vous sélectionnez pour voir si certaines peuvent être supprimées.