AnalyticDB for MySQL classe les requêtes lentes selon la ressource la plus sollicitée : mémoire, CPU ou E/S disque. Chaque catégorie dispose d’une métrique clé à surveiller dans la fonctionnalité de diagnostic SQL et présente des causes racines spécifiques.
Requêtes lentes consommant des ressources mémoire
Métrique clé : Peak Memory — quantité maximale de mémoire utilisée par une requête durant son exécution. Plus la valeur est élevée, plus la consommation mémoire est importante.
Pour repérer les requêtes gourmandes en mémoire, utilisez la fonctionnalité de diagnostic SQL afin de rechercher les requêtes longues, puis vérifiez la valeur Peak Memory dans la section Query Properties ou dans les résultats du diagnostic à différents niveaux. Pour en savoir plus, consultez la rubrique Afficher les propriétés des requêtes et les résultats du diagnostic.
Les opérations suivantes entraînent généralement une forte consommation mémoire :
| Cause | Impact sur la consommation mémoire |
|---|---|
| GROUP BY | AnalyticDB for MySQL met en cache les valeurs de colonne référencées dans les clauses GROUP BY. Plus le nombre de valeurs uniques est élevé, plus la mémoire consommée augmente. |
| JOIN (hash join) | AnalyticDB for MySQL charge les données d’une table en mémoire pour construire la table de hachage. Une table mise en cache plus volumineuse accroît l’utilisation de la mémoire. |
| SORT | AnalyticDB for MySQL met en cache les données en mémoire pendant le tri. Un volume de données à trier plus important nécessite davantage de mémoire. |
| Fonctions de fenêtrage | AnalyticDB for MySQL met en cache les données en mémoire lors de l’exécution des fonctions de fenêtrage. Plus les données d’entrée sont nombreuses, plus la consommation mémoire augmente. Pour en savoir plus, consultez la rubrique Fonctions de fenêtrage. |
Requêtes lentes consommant des ressources CPU
Métrique clé : Time Consumed — durée totale d’exécution d’une requête. Une durée plus longue indique une consommation CPU plus élevée.
Pour repérer les requêtes gourmandes en CPU, utilisez la fonctionnalité de diagnostic SQL afin de rechercher les requêtes longues, puis vérifiez la valeur Time Consumed dans la section Query Properties. Pour en savoir plus, consultez la rubrique Afficher les propriétés des requêtes.
Les éléments suivants entraînent généralement une forte consommation CPU :
| Cause | Impact sur la consommation CPU |
|---|---|
| Conditions de filtrage non propagées vers la couche de stockage | AnalyticDB for MySQL crée des index pour toutes les colonnes par défaut. L’utilisation des index pour filtrer les données réduit considérablement l’usage du CPU. Si les conditions de filtrage ne sont pas propagées, les index ne peuvent pas être exploités. Pour connaître les scénarios empêchant la propagation, consultez la rubrique Les conditions de filtrage ne sont pas propagées. |
| Opérations de filtrage intégrées aux conditions de jointure | Lorsqu’un filtre fait partie d’une condition de jointure au lieu d’être une clause WHERE autonome, AnalyticDB for MySQL joint d’abord les deux tables, puis filtre le résultat sans utiliser d’index. Un jeu de données intermédiaire volumineux issu de la jointure rend le filtrage ultérieur très gourmand en CPU. |
| Absence de condition de jointure spécifiée | Sans condition de jointure, AnalyticDB for MySQL effectue un produit cartésien : le jeu de résultats contient autant de lignes que le produit du nombre de lignes des tables de gauche et de droite. Les produits cartésiens sollicitent énormément le CPU. |
Requêtes lentes consommant des ressources d'E/S disque
Métriques clés : Scanned Rows et Scan Size — nombre de lignes et volume de données lus depuis le disque. Des valeurs plus élevées indiquent une charge d’E/S disque plus importante.
Pour repérer les requêtes gourmandes en E/S, utilisez la fonctionnalité de diagnostic SQL afin de rechercher les requêtes longues, puis vérifiez les valeurs Scanned Rows et Scan Size dans la section Query Properties ou dans les résultats du diagnostic à différents niveaux. Pour en savoir plus, consultez la rubrique Afficher les propriétés des requêtes et les résultats du diagnostic.
Les éléments suivants entraînent généralement une charge d’E/S disque élevée :
Les conditions de filtrage ne correspondent qu’à une petite fraction des données, ce qui réduit l’efficacité des index et oblige à lire un grand nombre d’entrées d’index.
Les conditions de filtrage ne sont pas propagées vers la couche de stockage, ce qui déclenche une analyse complète de la table source.
Les conditions de filtrage sont propagées, mais leur périmètre est large ; une grande quantité de données doit donc tout de même être analysée.
Un grand nombre de partitions doivent être analysées. Plus le nombre de partitions est élevé, plus le volume de données à lire est important.