La fonctionnalité de diagnostic SQL d'AnalyticDB for MySQL collecte des statistiques sur les requêtes SQL aux niveaux de la requête, de l'étape et de l'opérateur. Elle exploite ensuite ces données pour fournir des diagnostics et des suggestions d'optimisation. Cette rubrique explique comment consulter et analyser les résultats de diagnostic au niveau des opérateurs.
Types de résultats de diagnostic
Faible degré d'agrégation pour un opérateur d'agrégation
-
Problème
Le degré d'agrégation d'un opérateur correspond au rapport entre le volume de données en entrée (InputDataSize) et le volume de données en sortie (OutputDataSize) lors d'une opération GROUP BY. Un rapport faible indique un degré d'agrégation bas et une efficacité réduite. Dans AnalyticDB for MySQL, les opérations de regroupement et d'agrégation se déroulent en deux étapes : l'agrégation partielle (PARTIAL) et l'agrégation finale (FINAL). Si un opérateur d'agrégation gère de nombreux groupes, le degré d'agrégation est faible. L'étape d'agrégation partielle ne réduit alors pas le transfert de données sur le réseau et consomme au contraire d'importantes ressources de calcul.
-
Suggestion
Ignorez l'étape d'agrégation partielle. Redistribuez les données entre les nœuds, puis effectuez une seule agrégation finale. Pour plus d'informations, consultez Optimiser les requêtes de regroupement et d'agrégation.
Absence de propagation des conditions de filtre
-
Problème
AnalyticDB for MySQL
crée un index pour chaque champ d'une table lors du stockage des données. Ces index accélèrent le filtrage des données pendant les requêtes. Toutefois,
AnalyticDB for MySQL
ne propage pas les conditions de filtre dans les scénarios suivants :
La fonctionnalité de propagation des conditions de filtre est désactivée car l'instruction de requête utilise l'indicateur
no_index_columnsoufilter_not_pushdown_columns, ou le cluster utilise la configuration adb_config filter_not_pushdown_columns.La condition de filtre utilise une fonction, telle que l'opérateur
cast.Le champ concerné dans la condition de filtre ne possède pas d'index. Cela peut se produire si le mot-clé
no_indexa été spécifié lors de la création de la table, ou si l'index a été supprimé en exécutantDROP INDEXaprès la création de la table.
-
Suggestion
Si la fonctionnalité de propagation des conditions de filtre est désactivée en raison d'un indicateur dans l'instruction de requête ou d'une configuration du cluster, examinez la raison de cette utilisation et déterminez s'il est possible de la supprimer. Pour plus d'informations, consultez Ne pas propager les conditions de filtre.
Si une fonction est utilisée, appliquez-la lors de l'écriture des données, puis supprimez-la de la requête.
Si les conditions de filtre ne sont pas propagées car le champ concerné ne possède pas d'index, vérifiez pourquoi l'index est absent.
Gonflement des données lors d'une opération Join
-
Problème
Le taux de gonflement des données d'une opération Join correspond au rapport entre le nombre de lignes en sortie et le nombre de lignes en entrée. Le nombre de lignes en entrée est la somme des lignes des tables de gauche et de droite. Avec une condition de jointure appropriée, le nombre de lignes en sortie est généralement inférieur au nombre de lignes en entrée. Si le nombre de lignes en sortie est supérieur au nombre de lignes en entrée, un gonflement des données se produit. Ce phénomène consomme d'importantes ressources de calcul et de mémoire, ce qui ralentit la requête.
-
Suggestion
Si le gonflement des données est causé par les caractéristiques des données, par exemple la présence de nombreuses valeurs identiques dans les deux tables, filtrez ces valeurs lors de l'étape de filtrage de la table afin de les exclure de l'opération Join.
Si le gonflement des données est causé par un ordre de jointure sous-optimal, ajustez manuellement l'ordre de jointure. Pour plus d'informations, consultez Ajuster manuellement l'ordre de jointure.
Table de droite trop volumineuse dans une opération Join
-
Problème
Dans
AnalyticDB for MySQL
, la table de droite d'une opération Join est généralement la table de construction (builder), utilisée pour créer une structure de hachage ou d'ensemble en mémoire. Une table de droite volumineuse peut consommer des ressources mémoire excessives et affecter la stabilité globale du cluster. La table de droite peut être trop volumineuse pour les raisons suivantes :
L'instruction SQL contient une jointure Left Join. La table de droite d'une jointure Left Join doit être la table de construction lors de l'exécution. Par conséquent, si la table de droite dans une jointure Left Join est volumineuse, elle consomme une grande quantité de ressources mémoire.
AnalyticDB for MySQL effectue une estimation incorrecte du volume de données des tables de gauche et de droite. Cela peut être causé par des facteurs tels que des statistiques obsolètes.
-
Suggestion
Pour optimiser, nous vous recommandons de réécrire une jointure Left Join en tant que Right Join. Pour plus d'informations, consultez Réécrire une jointure Left Join en tant que Right Join.
Présence d'une opération Cross Join
-
Problème
Une opération Cross Join est une jointure sans condition de jointure. Le nombre de lignes en sortie est le produit du nombre de lignes des tables de gauche et de droite. Si les deux tables sont volumineuses, une opération Cross Join peut gravement affecter la stabilité du cluster AnalyticDB for MySQL.
-
Suggestion
Ajoutez une condition de jointure pour éliminer l'opération Cross Join.
Lecture excessive de champs par un opérateur de scan
-
Problème
Un opérateur de scan filtre et lit les données détaillées depuis la couche de stockage d'AnalyticDB for MySQL. Si une instruction SELECT inclut de nombreux champs, une grande quantité de données détaillées doit être lue. Cela consomme d'importantes ressources d'E/S disque et affecte la stabilité globale du cluster AnalyticDB for MySQL.
-
Suggestion
Optimisez l'instruction SQL pour supprimer les champs inutiles de l'instruction SELECT.
Déséquilibre des données lors d'un scan de table
-
Problème
AnalyticDB for MySQL utilise une architecture d'exécution distribuée. Pour les grandes tables, vous devez spécifier une clé de distribution. Les données sont distribuées vers différents nœuds de stockage en fonction de cette clé lors de l'écriture. Si les valeurs de la clé de distribution sont inégalement réparties, les données sont également stockées de manière inégale sur les nœuds. Cela provoque un effet de longue traîne lors de la lecture des données, où certains nœuds prennent beaucoup plus de temps que d'autres. Ce déséquilibre affecte négativement les performances des requêtes.
-
Suggestion
Réduisez le déséquilibre des données lors des scans de table en sélectionnant une clé de distribution appropriée. Pour plus d'informations sur les méthodes d'optimisation, consultez Diagnostic de l'espace de stockage.
Index inefficace
-
Problème
Lorsque AnalyticDB for MySQL utilise un index pour le filtrage des données, l'index peut ne pas fonctionner comme prévu si la sélectivité du champ filtré est faible. La sélectivité correspond au rapport entre le volume de données en sortie et le volume de données en entrée de l'opérateur de filtre.
-
Suggestion
Évitez de propager les conditions de filtre. Effectuez plutôt l'opération de filtrage directement sur les nœuds de calcul. Pour plus d'informations, consultez Ne pas propager les conditions de filtre.