Aller au contenu Aller au menu
Vous êtes ici : Développement > MySQL > 2) Indexer les données > b) Une forte cardinalité pour un bon index
Langue : fr

b) Une forte cardinalité pour un bon index

Premièrement, il faut choisir des champs qui ont une forte cardinalité (c'est-à-dire la plus grande variabilité possible des valeurs entre les enregistrements). Ils doivent avoir le plus grand nombre possible de valeurs distinctes. Par exemple, poser un index sur un champ 'genre' de type ENUM( 'masculin', 'féminin' ) n'a pas grand intérêt. Sur une table de 30 000 enregistrements, la valeur 'féminin' référence 15 000 enregistrements, qu'il faut parcourir séquentiellement dans l'index pour trouver les enregistrements correspondant aux critères de recherche, avant d'aller chercher les valeurs réelles dans la table, ce qui n'optimise pas beaucoup par rapport au parcours direct des 30 000 enregistrements. L'optimiseur de requêtes MySQL ne s'y trompe d'ailleurs pas : si le parcours d'un index retourne plus de la moitié des enregistrements d'une table, il n'utilise pas cet index (ce nombre jugé excessif peut descendre jusqu'à un tiers des enregistrements, suivant des paramètres de détermination internes à MySQL). Autant dire qu'il s'agit d'une perte de temps pour tout le monde.

A l'inverse, les champs d'identifiants sont toujours de bons candidats pour l'indexation, car ils ont une forte cardinalité. Un champ 'id_client' de type INT a par exemple une bonne tête de lauréat dans ce domaine. L'arbre résultant de cet index a une grande profondeur, et permet donc d'isoler un nombre très limité d'enregistrements. De façon plus générale, les clés étrangères (champs de référence vers les clés primaires d'autres tables) devraient toujours être indexées (c'est d'ailleurs une obligation avec InnoDB, devenu moteur de stockage par défaut dans MySQL 5).

  1. MySQL
    1. 1) Bien concevoir la base de données
      1. a) Choix des tables – Normalisation des données
      2. b) Choix et typage des champs
    2. 2) Indexer les données
      1. a) L'index : un marque-page dans la base de données
      2. b) Une forte cardinalité pour un bon index
      3. c) Une utilisation récurrente pour un bon index
      4. d) Gare aux contre-optimisations
    3. 3) Optimiser les requêtes SQL
      1. a) Utiliser la richesse du langage SQL
      2. b) Optimiser les jointures
      3. c) Mettre à profit une bonne indexation
    4. 4) Corriger les requêtes lentes
      1. a) L'optimisation de requête par EXPLAIN
      2. b) L'analyse post-mortem
    5. 5) Le serveur MySQL – maintenance et backup
      1. a) Minimiser l'impact des opérations de maintenance
      2. b) Sauvegarde et restauration des bases de données
      3. c) Maintenance des tables