Tous les produits
Search

Ce produit

    AnalyticDB:Statistiques

    Centre de documentation

    AnalyticDB:Statistiques

    Dernière mise à jour :Aug 10, 2026

    L'optimiseur de requêtes s'appuie sur les statistiques pour générer les plans d'exécution. Des statistiques de meilleure qualité conduisent à des plans plus efficaces et accélèrent l'exécution des requêtes. AnalyticDB for MySQL collecte automatiquement les statistiques pendant une fenêtre de maintenance configurable. Vous pouvez également déclencher leur collecte manuellement à tout moment à l'aide de ANALYZE TABLE.

    Éditions prises en charge

    La fonctionnalité de statistiques est prise en charge par les clusters Enterprise Edition, Basic Edition, Data Lakehouse Edition et Data Warehouse Edition disposant d'une version du noyau 3.1.6.1 ou ultérieure.

    Pour consulter et mettre à jour la version mineure d'un cluster AnalyticDB for MySQL, connectez-vous à la console AnalyticDB for MySQL et accédez à la section Configuration Information de la page Cluster Information.

    Types de statistiques

    AnalyticDB for MySQL prend en charge trois types de statistiques. Le choix du type approprié pour chaque colonne permet d'équilibrer la précision et l'utilisation du cache.

    Type Données capturées Cas d'utilisation recommandés
    Basique (BASIC) Valeurs maximale et minimale, longueur moyenne en octets, nombre de valeurs distinctes et ratio de valeurs NULL par colonne Colonnes non utilisées dans les filtres ou les jointures ; colonnes dont les données sont réparties uniformément, telles que les clés primaires
    Histogramme (HISTOGRAM) Répartition des données dans des compartiments ; sélection automatique entre l'histogramme hybride et l'histogramme de fréquence Colonnes présentant une distribution asymétrique des données et utilisées dans les filtres ou les jointures
    Groupe de colonnes (GROUP_STATS) Corrélation entre plusieurs colonnes d'une même table Agrégations multicolonnes impliquant des colonnes fortement corrélées
    Important

    Les statistiques de groupe de colonnes et la collecte par échantillonnage nécessitent une version du noyau 3.1.9.2 ou ultérieure.

    Statistiques basiques

    Les statistiques basiques capturent la valeur maximale, la valeur minimale, la longueur moyenne en octets, le nombre de valeurs distinctes et le ratio de valeurs NULL d'une colonne. Il s'agit du type de statistiques le plus léger, collecté via un balayage complet, un échantillonnage ou une mise à jour incrémentielle (mode incrémentiel par défaut).

    Privilégiez les statistiques basiques pour :

    • Les colonnes qui n'interviennent pas dans les opérations de filtrage ou de jointure.

    • Les colonnes dont les données sont réparties uniformément, comme les colonnes de clé primaire.

    Histogramme

    Un histogramme divise la plage de données d'une colonne en compartiments. Chaque compartiment décrit la répartition des données pour cette plage, offrant à l'optimiseur une vision plus précise de la fréquence des valeurs que ne le permettent les seules statistiques basiques.

    AnalyticDB for MySQL sélectionne automatiquement le type d'histogramme :

    • Histogramme hybride : Variante de l'histogramme à hauteur égale qui gère plus précisément les valeurs très fréquentes (hot spots).

    • Histogramme de fréquence : Destiné aux colonnes comportant peu de valeurs distinctes ; chaque valeur unique obtient son propre compartiment.

    Utilisez les histogrammes pour les colonnes dont la distribution des données est asymétrique et qui apparaissent dans les clauses WHERE ou les conditions de jointure. Pour les colonnes à distribution uniforme, les statistiques basiques suffisent.

    Compromis lié au cache : Les histogrammes offrent une meilleure précision mais consomment davantage de cache que les statistiques basiques. Le cache par défaut contient les statistiques d'environ 20 000 colonnes avec histogramme ou de 2 millions de colonnes avec statistiques basiques. Dans les schémas comportant de nombreuses tables, la collecte d'histogrammes pour toutes les colonnes peut réduire le taux de succès du cache.

    Statistiques de groupe de colonnes

    Important

    Les statistiques de groupe de colonnes nécessitent une version du noyau 3.1.9.2 ou ultérieure.

    L'optimiseur suppose que les colonnes sont indépendantes lorsqu'il estime le nombre de lignes pour des conditions multicolonnes. Lorsque les colonnes sont corrélées, cette hypothèse devient erronée et l'optimiseur produit des estimations inexactes, ce qui conduit à des plans de jointure et d'agrégation sous-optimaux.

    Les statistiques de groupe de colonnes capturent la corrélation entre plusieurs colonnes d'une même table. Lorsque les colonnes sont fortement corrélées, elles permettent à l'optimiseur de produire des estimations de lignes plus précises.

    Privilégiez les statistiques de groupe de colonnes pour les agrégations multicolonnes impliquant des colonnes fortement corrélées.

    Fonctionnement de la collecte automatique

    La collecte automatique des statistiques est activée par défaut. AnalyticDB for MySQL exécute deux modes de collecte :

    • Fenêtre de maintenance : Collecte complète ou par échantillonnage des statistiques basiques, des histogrammes et des statistiques de groupe de colonnes, en fonction du volume de données de la table. Une collecte complète portant sur de nombreuses colonnes peut prendre plusieurs jours.

    • En dehors de la fenêtre de maintenance : Collecte incrémentielle périodique des seules statistiques basiques.

    Comportement de collecte selon la méthode d'importation

    Méthode d'importation Comportement automatique Action recommandée
    INSERT OVERWRITE (lot) Collecte immédiate des statistiques basiques après l'importation Aucune action nécessaire
    INSERT INTO / REPLACE INTO (temps réel) Déclenchement de la collecte incrémentielle lors de la prochaine fenêtre de maintenance, ou pendant la période de collecte incrémentielle suivant la fin d'une tâche BUILD Collectez manuellement les statistiques basiques après l'importation
    La collecte automatique s'applique uniquement aux tables internes. La collecte manuelle s'applique aux tables internes et externes.

    Seuil de volume de données et échantillonnage

    Important

    La collecte par échantillonnage nécessite une version du noyau 3.1.9.2 ou ultérieure.

    Par défaut, les tables dépassant 5 000 000 000 lignes (5 milliards) déclenchent un comportement différent selon la version du noyau :

    • Version du noyau antérieure à 3.1.9.2 : La collecte des statistiques ignore la table.

    • Version du noyau 3.1.9.2 ou ultérieure : Les statistiques sont collectées par échantillonnage.

    Configurer la collecte automatique

    Activer ou désactiver la collecte automatique des statistiques

    La collecte automatique des statistiques est activée par défaut. Pour la désactiver ou la réactiver :

    SET adb_config O_CBO_AUTONOMOUS_STATS_ENABLED = [false|true];

    Activer ou désactiver la collecte des statistiques de groupe de colonnes

    Important

    La collecte des statistiques de groupe de colonnes nécessite une version du noyau 3.1.9.2 ou ultérieure, et la collecte automatique des statistiques doit être activée.

    La collecte des statistiques de groupe de colonnes est désactivée par défaut. Pour l'activer ou la désactiver :

    SET adb_config O_CBO_MAINTENANCE_WINDOW_COLLECT_GROUP_STATS_ENABLED = [false|true];

    Définir la fenêtre de maintenance

    La fenêtre de maintenance par défaut est fixée de 04:00 à 05:00, selon le fuseau horaire du cluster. Définissez-la pendant les heures creuses afin de minimiser l'impact sur les performances des requêtes.

    Contraintes :

    • L'intervalle entre l'heure de début et l'heure de fin doit être d'au moins 1 minute et d'au plus 3 heures.

    • L'heure de début doit être antérieure à l'heure de fin.

    • Une heure invalide entraîne le retour aux paramètres par défaut.

    SET adb_config O_CBO_MAINTENANCE_WINDOW_DURATION = [04:00-05:00];

    Définir le seuil de volume de données

    Pour modifier le seuil de nombre de lignes déclenchant l'échantillonnage (par défaut : 5 000 000 000) :

    SET adb_config O_CBO_MAINTENANCE_WINDOW_COLLECTOR_ROW_LIMIT = 10000;

    Activer ou désactiver la limitation des E/S

    Pendant la fenêtre de maintenance, AnalyticDB for MySQL applique une limitation des entrées/sorties (E/S) afin de limiter l'utilisation des ressources lors du balayage des tables. Cette limitation est activée par défaut. Si les ressources sont inactives pendant la fenêtre de maintenance, désactivez la limitation pour accélérer la collecte :

    SET adb_config O_CBO_AUTONOMOUS_STATS_SCAN_RATE_LIMIT_ENABLED = [false|true];

    Exécuter la collecte dans un groupe de ressources spécifique

    Par défaut, la collecte automatique s'exécute sous un compte système. Pour l'exécuter dans un groupe de ressources spécifique, spécifiez un compte de base de données :

    SET adb_config O_CBO_AUTONOMOUS_STATS_ACCOUNT = [user_name];

    Le compte spécifié doit disposer d'autorisations de lecture sur toutes les colonnes de toutes les tables et être associé à un groupe de ressources. Pour plus d'informations, consultez la rubrique Créer et gérer des groupes de ressources.

    Définir le ratio d'expiration

    Les statistiques sont considérées comme expirées lorsque la fraction de lignes modifiées par les opérations UPDATE, DELETE, INSERT ou REPLACE dépasse le ratio d'expiration. Les statistiques expirées sont entièrement recueillies lors de la prochaine fenêtre de maintenance.

    Le ratio d'expiration par défaut est de 0,1 (10 %). Pour l'ajuster :

    SET adb_config O_CBO_STATS_EXPIRED_RATIO = 0.1;

    Plage valide : 0–1. Évitez de définir une valeur supérieure à 0,5.

    Collecter manuellement les statistiques

    Utilisez ANALYZE TABLE pour collecter les statistiques à la demande. La collecte manuelle s'applique aux tables internes et externes.

    Pour les tables volumineuses, privilégiez l'échantillonnage (WITH ENABLE SAMPLING) plutôt qu'un balayage complet. Effectuez la collecte sur l'intégralité de la table pendant les heures creuses lorsque l'échantillonnage n'est pas disponible.

    Collecter les statistiques sur une table

    ANALYZE TABLE [schema_name.]table_name [UPDATE [BASIC|HISTOGRAM|GROUP_STATS]] [ON column_name[,...]] [WITH ENABLE SAMPLING]
    Paramètre Obligatoire Description
    schema_name Non Nom de la base de données.
    table_name Oui Table à analyser. Chaque instruction ne peut spécifier qu'une seule table. Prend en charge les tables internes et externes.
    `UPDATE [BASIC HISTOGRAM GROUP_STATS]`

    Non

    Type de statistiques à collecter. La valeur par défaut est BASIC. GROUP_STATS nécessite une version du noyau 3.1.9.2 ou ultérieure.
    ON column_name[,...] Non Colonnes à analyser. Omettez ce paramètre pour analyser toutes les colonnes.
    WITH ENABLE SAMPLING Non Collecte par échantillonnage au lieu d'un balayage complet. Nécessite une version du noyau 3.1.9.2 ou ultérieure.

    Exemples

    Collecte des statistiques basiques sur toutes les colonnes de adb_demo.customer :

    ANALYZE TABLE adb_demo.customer;
-- Equivalent:
ANALYZE TABLE adb_demo.customer UPDATE BASIC;

    Collecte des statistiques basiques sur la seule colonne customer_id :

    ANALYZE TABLE adb_demo.customer UPDATE BASIC ON customer_id;

    Collecte des statistiques d'histogramme sur customer_id et login_time :

    ANALYZE TABLE adb_demo.customer UPDATE HISTOGRAM ON customer_id, login_time;

    Collecte des statistiques de groupe de colonnes par échantillonnage sur customer_id et login_time :

    ANALYZE TABLE adb_demo.customer UPDATE GROUP_STATS ON customer_id, login_time WITH ENABLE SAMPLING;

    Collecter les statistiques sur des partitions

    La collecte de statistiques au niveau des partitions est prise en charge par les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition disposant d'une version du noyau 3.1.9.1 ou ultérieure. Cette opération effectue une collecte complète des statistiques basiques sur les partitions des tables externes OSS.
    ANALYZE TABLE table_name WITH PARTITIONS = ARRAY[ARRAY[PARTITION_KEYS] [, PARTITION_KEYS, ...]]
    Paramètre Obligatoire Description
    table_name Oui Table à analyser. Chaque instruction ne peut spécifier qu'une seule table.
    PARTITION_KEYS Oui Partitions à analyser.

    Exemples

    Collecte des statistiques sur les partitions 2023-01 et 2023-02 de test1 :

    ANALYZE TABLE test1 WITH PARTITIONS = ARRAY[ARRAY['2023-01'], ARRAY['2023-02']];

    Collecte des statistiques sur les partitions (1,1) et (1,0) de test2 :

    ANALYZE TABLE test2 WITH PARTITIONS = ARRAY[ARRAY[1, 1], ARRAY[1, 0]];

    Consulter les statistiques

    Les statistiques sont stockées au format binaire. Interrogez les tables système INFORMATION_SCHEMA pour les inspecter.

    Consultez les statistiques au niveau de la table :

    SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS;

    Consultez les statistiques au niveau de la colonne (basiques, histogrammes et groupes de colonnes) :

    SELECT * FROM INFORMATION_SCHEMA.COLUMN_STATISTICS;

    FAQ

    Pourquoi l'instruction ANALYZE apparaît-elle comme une requête lente ?

    Les instructions ANALYZE exécutées pendant la fenêtre de maintenance subissent une limitation des E/S et une priorité CPU faible. Par conséquent, leur durée d'exécution peut être longue et elles peuvent être signalées comme requêtes lentes, sans toutefois affecter les performances des requêtes classiques. Les ressources sont allouées en priorité aux requêtes utilisateur dès leur arrivée.

    Si la charge CPU n'est pas élevée en dehors de la fenêtre de maintenance, ignorez le signalement de requête lente. Si une surcharge CPU affecte le temps de réponse des requêtes, suivez les étapes de dépannage ci-dessous.

    Quelles sont les causes d'une charge CPU élevée pendant la collecte des statistiques ?

    Deux causes courantes existent :

    • Pendant la fenêtre de maintenance (par défaut de 04:00 à 05:00) : Le système effectue un balayage complet de la table pour collecter les statistiques des colonnes, ce qui augmente temporairement l'utilisation du processeur.

    • Après une mise à jour de la version mineure vers la version 3.1.6 ou ultérieure pour les clusters Data Warehouse Edition : Si le cluster est mis à niveau depuis une version antérieure, AnalyticDB for MySQL effectue une collecte complète unique. La charge CPU peut rester élevée pendant les premiers jours, puis revenir à la normale une fois le balayage initial terminé.

    Dans les deux cas, vérifiez si le temps de réponse moyen des requêtes est réellement affecté. Étant donné que ANALYZE s'exécute avec une priorité CPU faible, une utilisation élevée du processeur pendant la collecte ne signifie pas que les requêtes manquent de ressources.

    Que faire si la collecte des statistiques dégrade les performances des requêtes ?

    Essayez ces étapes dans l'ordre :

    1. Reprogrammez la fenêtre de maintenance pendant vos véritables heures creuses :

      SET adb_config O_CBO_MAINTENANCE_WINDOW_DURATION = [04:00-05:00];

    2. Ajustez la limite d'E/S pour les requêtes système si vous ne parvenez pas à identifier clairement une période creuse. Nous recommandons de définir la limite d'E/S sur une valeur supérieure ou égale à 16 Mo. La valeur par défaut est de 50 Mo :

      SET adb_config CSTORE_IO_LIMIT_SYSTEM_QUERY_BPS = 52428800;

    3. Isolez la collecte dans un groupe de ressources à faible priorité afin d'éviter toute concurrence avec les requêtes utilisateur :

      SET adb_config O_CBO_AUTONOMOUS_STATS_ACCOUNT = [user_name];

    4. Augmentez le ratio d'expiration pour réduire la quantité de données recueillies à chaque cycle. La valeur par défaut est de 0,1 ; évitez de la définir au-delà de 0,5 :

      SET adb_config O_CBO_STATS_EXPIRED_RATIO = 0.1;

    Si aucune des solutions précédentes ne résout le problème, désactivez la collecte automatique et passez à la collecte manuelle :

    SET adb_config O_CBO_AUTONOMOUS_STATS_ENABLED = false;

    Après la désactivation, collectez les statistiques manuellement à l'aide de ANALYZE TABLE . En l'absence de collecte automatique, les statistiques peuvent devenir obsolètes, ce qui risque de dégrader la qualité des plans de requête au fil du temps.

    Pourquoi les statistiques n'ont-elles pas été mises à jour depuis plusieurs jours ?

    Deux explications sont probables :

    • Les statistiques n'ont pas encore expiré. L'expiration survient uniquement lorsque la fraction de lignes modifiées (via UPDATE, DELETE, INSERT ou REPLACE) dépasse le ratio d'expiration (par défaut : 10 %). Si les modifications de données sont faibles par rapport à la taille totale de la table, les statistiques sont considérées comme actuelles et ne sont pas recueillies à nouveau.

    • Les schémas volumineux prennent plus d'une journée. Le système alloue environ 1 heure par jour à la collecte non incrémentielle des statistiques. Si un cluster comporte plus de 1 000 colonnes, un passage complet peut prendre jusqu'à une semaine. Ce comportement est attendu : les requêtes continuent de s'exécuter et les statistiques sont mises à jour au fur et à mesure de l'achèvement du cycle.

    Les statistiques sont-elles collectées automatiquement lors de l'importation de données dans une nouvelle table ?

    Cela dépend de la méthode d'importation :

    • INSERT OVERWRITE (importation par lot) : Les statistiques basiques sont automatiquement collectées immédiatement après la fin de l'importation.

    • INSERT INTO ou REPLACE INTO (importation en temps réel) : Les statistiques sont collectées lors de la prochaine fenêtre de maintenance, ou pendant la période de collecte incrémentielle suivant la fin d'une tâche BUILD. Exécutez ANALYZE TABLE immédiatement après l'importation pour collecter sans délai les statistiques basiques.