Tous les produits
Search

Ce produit

    AnalyticDB:Diagnostic du stockage

    Centre de documentation

    AnalyticDB:Diagnostic du stockage

    Dernière mise à jour :Sep 22, 2026

    Le diagnostic du stockage vous aide à identifier les déséquilibres de données, les clés de partition sous-optimales, les index excessifs et d'autres problèmes de configuration de table dans votre cluster AnalyticDB for MySQL. Sur la page Storage Diagnostics, vous pouvez évaluer l'adéquation des clés de partition, des clés de distribution et des tables répliquées. Vous pouvez également identifier les opportunités de séparation des données chaudes et froides et recevoir des suggestions d'optimisation des index. En appliquant ces recommandations, vous optimisez le schéma de votre base de données, réduisez les coûts du cluster et améliorez l'efficacité.

    Remarques importantes

    • L'optimisation des tables chaudes et froides ainsi que le diagnostic des index sont pris en charge uniquement sur les clusters exécutant Milvus version 3.1.4 ou ultérieure.

    • Les suggestions d'optimisation pour la séparation des données chaudes et froides et le diagnostic des index reposent sur une analyse historique des données et des modèles de requêtes. Ces suggestions restent pertinentes tant que les données et les modèles de requêtes demeurent stables. Si ces modèles évoluent de manière significative, l'efficacité des suggestions diminue. Avant d'utiliser cette fonctionnalité, évaluez s'il convient d'appliquer les suggestions en fonction de votre charge de travail actuelle.

    Diagnostic des tables

    Diagnostic du déséquilibre des données

    Lorsque vous créez une table, utilisez DISTRIBUTED BY HASH pour spécifier une clé de distribution. Après avoir défini la clé de distribution, AnalyticDB for MySQL calcule un hachage des valeurs de la clé de distribution et répartit les lignes sur différents shards. Une distribution inégale des données entre les nœuds de stockage entraîne un déséquilibre de l'espace disque, ce qui peut remplir prématurément les disques et bloquer les écritures de données.

    Critères de diagnostic

    AnalyticDB for MySQL diagnostique le déséquilibre des données pour les tables contenant plus de 10 000 lignes. La méthode de calcul est la suivante :

    1. Excluez le shard le plus volumineux et calculez la taille moyenne des shards.

    2. Si un shard est supérieur à average shard size × threshold ou inférieur à average shard size / threshold, la table est considérée comme déséquilibrée. Le seuil par défaut est 3 et la plage valide est [0, 10000000000]. Vous pouvez ajuster le seuil en exécutant la commande suivante : SET ADB_CONFIG RC_DATA_SKEW_THRESHOLD=Value;.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster à gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Table Diagnostics pour afficher les détails dans la section Table Skew Diagnostics.

      Storage Node Disk Usage

      Utilisez le graphique pour vérifier l'utilisation du disque sur les nœuds de stockage et identifier tout déséquilibre de l'espace disque. En cas de déséquilibre, optimisez les tables répertoriées sous Top 10 Skewed Tables. Même si l'espace disque semble équilibré mais que des tables apparaissent dans Top 10 Skewed Tables, optimisez-les afin d'éviter toute dégradation des performances des requêtes du cluster.

      Top 10 Skewed Tables

      Cette section répertorie les tables présentant un déséquilibre de données, triées par volume total de données décroissant. Pour afficher le nombre de lignes par shard et évaluer la gravité du déséquilibre, cliquez sur View Skew Details dans la colonne Actions.

    Méthodes d'optimisation

    Vous pouvez résoudre ce problème en utilisant l'une des méthodes suivantes :

    • Augmentez la capacité de stockage.

    • Supprimez les index ou partitions inutilisés pour réduire l'utilisation du stockage. Pour plus d'informations, consultez la section Diagnostic des index.

    • Recréez la table et migrez les données. Pour plus d'informations, consultez la rubrique CREATE TABLE.

    Optimisation des tables chaudes et froides

    AnalyticDB for MySQL analyse la fréquence d'accès aux tables pour identifier les tables rarement consultées et fournir des suggestions d'optimisation. Vous pouvez appliquer ces recommandations pour ajuster la politique de séparation des données chaudes et froides de vos tables. Pour plus d'informations sur la séparation des données chaudes et froides, consultez la rubrique Hot and cold data separation.

    Critères de diagnostic

    AnalyticDB for MySQL fournit des suggestions d'optimisation pour les tables qui n'ont pas été consultées au cours des 15 derniers jours et dont le taux d'accès est inférieur à 1 %.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster à gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Sous l'onglet Table Diagnostics, cliquez sur Hot and Cold Table Optimization.

    4. Sous l'onglet Available Optimization Suggestions, cliquez sur Disable pour activer la fonctionnalité d'optimisation des tables chaudes et froides. Si cette fonctionnalité est déjà activée pour le cluster actuel, ignorez cette étape.

    5. Cliquez sur les onglets Available Optimization Suggestions et Applied Optimization Suggestions pour consulter les suggestions disponibles et celles déjà appliquées.

      Paramètre

      Description

      Suggestion ID

      Identifiant de la suggestion d'optimisation.

      SQL

      Modifications de table et de définition requises par la suggestion.

      Optimization Type

      Optimisation des tables chaudes et froides.

      Optimization Suggestion

      Recommandation détaillée pour le type d'optimisation.

      Expected Optimization Benefits

      Bénéfice attendu après application de la suggestion.

      Remarque

      Les avantages attendus sont des estimations basées sur des statistiques historiques et non des valeurs précises en temps réel. Utilisez-les à titre indicatif uniquement.

      Actions

      Vous pouvez appliquer la suggestion actuelle en cliquant sur Apply.

      Remarque

      • Après avoir cliqué sur Apply, AnalyticDB for MySQL modifie la stratégie de stockage de la table en COLD. Pour la passer à MIXED ou HOT, exécutez manuellement une instruction ALTER. Pour plus de détails, consultez la section Stratégies de stockage.

      • Cliquez sur Apply pour adopter la suggestion d'optimisation. Après avoir cliqué sur Apply, le cluster correspondant exécute la modification SQL et la suggestion apparaît sous l'onglet Applied Optimization Suggestions.

      • Apply produit le même effet que l'exécution du code SQL dans un client. Cette action est irréversible. Utilisez-la avec précaution.

      • Une fois le code SQL envoyé, la table doit terminer une opération Build pour que la modification prenne effet. Le système de base de données déclenche automatiquement l'opération Build selon des règles internes. Jusqu'au déclenchement, le statut de la suggestion reste « en cours d'exécution ». Après le déclenchement, il passe à « terminé ».

    Diagnostic des tables répliquées

    Lorsque vous créez une table dans AnalyticDB for MySQL, vous pouvez spécifier une distribution par diffusion à l'aide de DISTRIBUTED BY BROADCAST. La table est alors créée en tant que table répliquée, qui stocke une copie identique de ses données sur chaque shard. Si votre charge de requêtes implique des jointures à haute concurrence entre des tables volumineuses et des tables de petite taille, telles que la jointure d'une grande table de faits avec une petite table de dimensions, vous pouvez créer la table la plus petite en tant que table répliquée. Cela permet de réduire la transmission de données sur le réseau interne du cluster et d'améliorer la concurrence des requêtes. Toutefois, les tables répliquées offrent de mauvaises performances en écriture et consomment beaucoup d'espace de stockage, ce qui peut nuire aux performances globales en écriture du cluster AnalyticDB for MySQL.

    Critères de diagnostic

    Une table répliquée est considérée comme inefficace si elle contient plus de 20 000 lignes.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster à gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Sous l'onglet Table Diagnostics, cliquez sur Replicated Table Diagnostics.

    Méthodes d'optimisation

    Créez une table standard et migrez les données. Pour plus d'informations, consultez la rubrique CREATE TABLE.

    Diagnostic des partitions

    Diagnostic des tables partitionnées

    Si vous ne définissez pas correctement le champ de partition lors de la création d'une table partitionnée, les problèmes suivants peuvent survenir :

    • Des partitions trop volumineuses, telles que des partitions annuelles où toutes les données d'une année résident dans une seule partition, entraînent un nombre réduit de partitions contenant des volumes de données massifs. L'exécution d'une tâche Build sur une telle partition consomme des ressources excessives, notamment le processeur du nœud de stockage et les E/S disque, ce qui affecte la stabilité du cluster.

    • Des partitions trop petites, telles que des partitions horaires où les données de chaque heure résident dans une seule partition, génèrent de nombreuses partitions contenant peu de données. Le cluster doit mettre en cache d'importantes métadonnées de partition, ce qui consomme une quantité significative de mémoire. Les requêtes doivent également analyser de nombreuses partitions, ce qui dégrade les performances des requêtes.

    Quelle est la taille de partition raisonnable ?

    La taille de la partition est mesurée par le nombre de lignes1 et évolue proportionnellement au nombre de shards2. Si un cluster comporte N shards, une taille de partition raisonnable correspond à un nombre de lignes compris entre [1 million × N] et [5 millions × N].

    Par exemple, si un cluster dispose de 64 shards, un nombre de lignes raisonnable par partition varie de 64 millions à 320 millions.

    Remarque

    • 1Pour interroger le nombre de lignes par partition, exécutez la commande suivante : SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;

    • 2Pour interroger le nombre de shards, exécutez la commande suivante : SELECT COUNT(1) FROM information_schema.kepler_meta_shards;

    Diagnostiquer la pertinence du champ de partition

    Critères de diagnostic

    Un champ de partition est considéré comme inapproprié si 10 % ou plus des partitions d'une table ont une taille inappropriée.

    Par exemple, si une table compte 100 partitions et que 10 d'entre elles ou plus ont une taille inappropriée, le champ de partition est signalé comme inapproprié.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster que vous souhaitez gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Partition Diagnostics pour afficher les tables partitionnées inappropriées et leurs noms de partition spécifiques dans la section Partitioned Table Diagnostics.

    Comment ajuster la taille des partitions dans la plage raisonnable

    Si l'outil de diagnostic des partitions identifie des partitions inappropriées, vous pouvez utiliser les méthodes suivantes pour les ajuster.

    • Si le nombre de lignes d'une partition est inférieur à la limite inférieure de la plage raisonnable, la partition est trop petite. Dans ce cas, vous pouvez augmenter la granularité de la partition. Par exemple, si un cluster dispose de 64 shards, la plage raisonnable s'étend de 64 millions à 320 millions de lignes. Si une partition contient moins de 64 millions de lignes, vous pouvez modifier le partitionnement de quotidien à mensuel.

    • Si le nombre de lignes d'une partition dépasse la limite supérieure recommandée, la partition est considérée comme trop grande et vous devez réduire sa granularité. Par exemple, si vous disposez de 64 shards, le nombre recommandé de lignes par partition se situe entre 64 millions et 320 millions. Si une partition contient plus de 320 millions de lignes, nous vous recommandons de modifier le partitionnement de mensuel à quotidien.

      Pour plus d'informations sur la modification de la granularité des partitions, consultez la rubrique Modifier le format de la fonction de partition.

    • Si le nombre total de lignes d'une table est inférieur à la limite inférieure de la plage raisonnable et qu'il n'est pas prévu d'atteindre cette plage, vous pouvez créer une table non partitionnée et migrer les données depuis la table partitionnée.

    Diagnostic des tables non partitionnées

    Si vous omettez la clause PARTITION BY lors de la création d'une table, celle-ci est créée en tant que table non partitionnée. Les opérations DML, telles que INSERT, UPDATE et DELETE, sur les tables non partitionnées déclenchent souvent des tâches Build sur l'ensemble de la table. Si la table contient une quantité excessive de données, ces tâches Build consomment beaucoup d'espace disque temporaire, ce qui augmente l'utilisation du disque sur le nœud et peut verrouiller les disques. Les tâches Build sur les grandes tables consomment également d'importantes ressources d'E/S disque et de processeur, ce qui dégrade les performances globales du cluster.

    Critères de diagnostic

    Une table non partitionnée est considérée comme inefficace si elle contient plus d'un milliard de lignes.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster que vous souhaitez gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Partition Diagnostics pour afficher les informations relatives à la section Non-partitioned Table Diagnostics.

    Méthodes d'optimisation

    Créez une table partitionnée et migrez les données depuis la table non partitionnée. Pour plus d'informations, consultez la rubrique CREATE TABLE.

    Diagnostic des index

    AnalyticDB for MySQL analyse l'utilisation des index et fournit automatiquement des suggestions d'optimisation pour les index qui n'ont pas été utilisés depuis longtemps. Vous pouvez appliquer ces suggestions pour supprimer les index inutilisés et réduire les coûts de stockage.

    Diagnostic des index inutilisés

    Critères de diagnostic

    Un index est considéré comme inutilisé s'il n'a pas été utilisé au cours des 15 derniers jours et si son taux d'utilisation est inférieur à 1 %.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster que vous souhaitez gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Index Diagnostics pour afficher les détails de la section Indexes to Remove.

    4. Dans l'onglet Available Optimization Suggestions , cliquez sur Enable pour activer le diagnostic des index. Vous pouvez ignorer cette étape si cette fonctionnalité est déjà activée.

    5. Cliquez sur les onglets Available Optimization Suggestions et Applied Optimization Suggestions pour afficher les suggestions disponibles et appliquées.

      Paramètre

      Description

      Suggestion ID

      ID de la suggestion d'optimisation.

      SQL

      Modifications de table et de définition requises par la suggestion.

      Optimization Type

      Optimisation des index.

      Optimization Suggestion

      Recommandation détaillée pour le type d'optimisation.

      Expected Optimization Benefits

      Avantage attendu après application de la suggestion.

      Remarque

      Les avantages attendus sont des estimations basées sur des statistiques historiques et non des valeurs précises en temps réel. Utilisez-les uniquement à titre de référence.

      Actions

      Vous pouvez appliquer la suggestion actuelle en utilisant Apply.

      Remarque

      • Après la suppression d'un index, les requêtes filtrant sur cette colonne prendront plus de temps.

      • Apply indique que vous acceptez d'adopter cette suggestion d'optimisation. Après avoir cliqué sur Apply, le cluster correspondant exécute les modifications SQL et cette suggestion apparaît dans l'onglet Applied Optimization Suggestions.

      • Apply a le même effet que l'exécution du code SQL dans un client. Cette action est irréversible. Utilisez-la avec précaution.

      • Après l'émission du code SQL, la table doit terminer une opération Build pour que la modification prenne effet. Le système de base de données déclenche automatiquement l'opération Build selon des règles internes. Jusqu'au déclenchement, l'état de la suggestion reste « running ». Après le déclenchement, il passe à « completed ».

    Diagnostic des nouveaux index

    Critères de diagnostic

    Ce diagnostic identifie les champs qui ont été utilisés comme filtres dans les requêtes au cours des 15 derniers jours, mais qui ne sont pas définis comme champs indexés.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster que vous souhaitez gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Index Diagnostics pour afficher les détails de la section Indexes to Create.

    4. Dans l'onglet Available Optimization Suggestions , cliquez sur Enable pour activer le diagnostic des index. Vous pouvez ignorer cette étape si cette fonctionnalité est déjà activée.

    5. Cliquez sur les onglets Available Optimization Suggestions et Applied Optimization Suggestions pour afficher les suggestions disponibles et appliquées.

      Paramètre

      Description

      Suggestion ID

      ID de la suggestion d'optimisation.

      Index Fields

      Champ à ajouter en tant qu'index.

      SQL

      Instruction SQL pour créer l'index.

      Optimization Type

      Suggestion de création d'index.

      Optimization Suggestion

      Décrit la fréquence d'utilisation récente du champ, indiquant son potentiel en tant que champ indexé.

      Vous pouvez appliquer la suggestion actuelle en utilisant Batch Create.

      Remarque

      Après l'ajout à la section Indexes to Create, la table doit terminer une opération Build pour que la modification prenne effet. Le système de base de données déclenche automatiquement l'opération Build selon des règles internes. Jusqu'au déclenchement, l'état de la suggestion reste « running ». Après le déclenchement, il passe à « completed ».

    Diagnostic des index de clé primaire

    Critères de diagnostic

    Une table est considérée comme ayant un nombre excessif de clés primaires si elle possède plus de trois champs de clé primaire et si ces champs constituent au moins la moitié de tous les champs de la table.

    Procédure

    1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Recherchez le cluster que vous souhaitez gérer et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, choisissez Storage Analysis > Storage Diagnostics.

    3. Cliquez sur l'onglet Index Diagnostics pour afficher les détails de la section Primary Key Diagnostics.

    4. Dans l'onglet Available Optimization Suggestions , cliquez sur Enable pour activer le diagnostic des index. Vous pouvez ignorer cette étape si cette fonctionnalité est déjà activée.

    5. Consultez les tables présentant un nombre excessif de clés primaires. Le tableau affiche les colonnes suivantes : Database , Table Name , Table Fields et Primary Key Fields .

    FAQ

    Pourquoi l'état de la tâche d'optimisation reste-t-il « running » après avoir cliqué sur Apply now pour une suggestion d'optimisation de table chaude et froide ?

    Cause : Après avoir cliqué sur Apply , AnalyticDB for MySQL modifie la politique de stockage de la table en COLD. Cette modification nécessite une opération Build pour prendre effet. La fonctionnalité d'optimisation des données chaudes et froides ne déclenche pas immédiatement une tâche Build. Le système déclenche automatiquement cette tâche ultérieurement.

    Solution : Vous pouvez attendre que le système déclenche automatiquement la tâche Build , ou copier l'instruction SQL qui déclenche la tâche Build depuis la console et l'exécuter manuellement. Une fois la tâche Build exécutée, vous pouvez vérifier son état en exécutant la commande suivante : SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10; .

    API associées

    API

    Description

    DescribeExcessivePrimaryKeys

    Affichez les tables avec un nombre excessif de clés primaires dans les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition .

    DescribeTablePartitionDiagnose

    Affichez le diagnostic des partitions pour les clusters Data Warehouse Edition .