Tous les produits
Search

Ce produit

    AnalyticDB:Diagnostic du stockage

    Centre de documentation

    AnalyticDB:Diagnostic du stockage

    Dernière mise à jour :Aug 10, 2026

    Le diagnostic du stockage vous aide à identifier les déséquilibres de données (data skew), les clés de partition sous-optimales, les index excessifs et d'autres problèmes de configuration des tables 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/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 changent considérablement, l'efficacité des suggestions diminue. Avant d'utiliser cette fonctionnalité, évaluez si l'application des suggestions est appropriée à 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 provoque 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 de 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 déséquilibrées apparaissent dans Top 10 Skewed Tables, optimisez-les afin d'éviter toute dégradation des performances de requête du cluster.

      Top 10 Skewed Tables

      Cette section liste 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.

      • Les clusters Enterprise Edition nécessitent une mise à l'échelle des ressources réservées. Pour plus d'informations, consultez la rubrique Scale an Enterprise Edition cluster.

      • Les clusters Basic Edition nécessitent une mise à l'échelle des ressources de calcul. Pour plus d'informations, consultez la rubrique Scale a Basic Edition cluster.

      • Les clusters Data Lakehouse Edition nécessitent une mise à l'échelle des ressources de stockage réservées. Pour plus d'informations, consultez la rubrique 湖仓版扩缩容.

      • Les clusters Data Warehouse Edition (elastic mode) nécessitent une mise à l'échelle des unités d'E/S élastiques. Pour plus d'informations, consultez la rubrique Scale a Data Warehouse Edition (elastic mode) cluster.

      • Les clusters Data Warehouse Edition (reserved mode) nécessitent une mise à l'échelle des groupes de nœuds. Pour plus d'informations, consultez la rubrique Scale a Data Warehouse Edition (reserved mode) cluster.

    • 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 qui ont été appliquées.

      Paramètre

      Description

      Suggestion ID

      ID de la suggestion d'optimisation.

      SQL

      Modifications de la table et de sa 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

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

      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 changer en MIXED ou HOT, exécutez manuellement une instruction ALTER. Pour plus de détails, consultez ALTER TABLE.

      • 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 SQL dans un client. Cette action est irréversible. Utilisez-la avec précaution.

      • Une fois l'instruction SQL émise, 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 tables répliquées

    Lors de la création d'une table dans AnalyticDB for MySQL, vous pouvez spécifier une distribution par diffusion en utilisant 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 travail de requêtes implique des jointures à haute concurrence entre de grandes et de petites tables, 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 présentent de mauvaises performances en écriture et consomment beaucoup d'espace de stockage, ce qui peut nuire aux performances globales d'é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ù les données de chaque année résident dans une seule partition, entraînent un petit nombre de partitions contenant des volumes de données massifs. Si une tâche Build s'exécute sur une telle partition, elle consomme des ressources excessives, telles que le CPU des nœuds 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 d'interrogation.

    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 dispose de 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 compte 64 shards, le nombre raisonnable de lignes 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 si le champ de partition est raisonnable

    Critères de diagnostic

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

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

    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 Partition Diagnostics pour afficher les tables partitionnées problématiques 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 déraisonnables, 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, augmentez la granularité de la partition. Par exemple, si un cluster compte 64 shards, la plage raisonnable va de 64 millions à 320 millions de lignes. Si une partition contient moins de 64 millions de lignes, vous pouvez passer d'un partitionnement quotidien à un partitionnement 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, avec 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 passer d'un partitionnement mensuel à un partitionnement quotidien.

      Pour plus d'informations sur la modification de la granularité des partitions, consultez la rubrique ALTER TABLE.

    • 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, créez une table non partitionnée et migrez 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'intégralité 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 de grandes tables consomment également d'importantes ressources d'E/S disque et de CPU, 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 à 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 de 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 inutilisés depuis longtemps. Vous pouvez appliquer ces recommandations pour supprimer les index inactifs et réduire les coûts de stockage.

    Diagnostic des index inactifs

    Critères de diagnostic

    Un index est considéré comme inactif 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 à 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 Indexes to Remove.

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

    5. Cliquez sur les onglets Available Optimization Suggestions et Applied Optimization Suggestions pour consulter les suggestions disponibles et celles qui ont été appliquées.

      Paramètre

      Description

      Suggestion ID

      ID de la suggestion d'optimisation.

      SQL

      Modifications de la table et de sa 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 indicatif.

      Actions

      Vous pouvez appliquer la suggestion actuelle en cliquant sur Apply.

      Remarque

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

      • Apply signifie 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 sous l'onglet Applied Optimization Suggestions.

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

      • Une fois l'instruction SQL émise, 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 à 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 Indexes to Create.

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

    5. Cliquez sur les onglets Available Optimization Suggestions et Applied Optimization Suggestions pour consulter les suggestions disponibles et celles qui ont été 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 cliquant sur Batch Create.

      Remarque

      Après la création via 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 comporte plus de trois champs de clé primaire et que 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 à 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 Primary Key Diagnostics.

    4. Sous l'onglet Available Optimization Suggestions, cliquez sur Enable pour activer le diagnostic des index. Ignorez cette étape si la 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 pour une suggestion d'optimisation de table chaude et froide ?

    Cause : Après avoir cliqué sur Apply, AnalyticDB for MySQL modifie la stratégie 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 : Attendez que le système déclenche automatiquement la tâche Build, ou copiez l'instruction SQL qui déclenche la tâche Build depuis la console et exécutez-la manuellement. Une fois la tâche Build exécutée, vérifiez 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 connexes

    |
    API
    |
    Description
    | | --- | --- | |
    [DescribeExcessivePrimaryKeys](t2735861.xdita#)
    |
    Affichez les tables présentant un nombre excessif de clés primaires dans les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition.
    | |
    [DescribeTablePartitionDiagnose](t2308489.xdita#)
    |
    Affichez le diagnostic des partitions pour les clusters Data Warehouse Edition.
    |