Aller au contenu Aller au menu
Vous êtes ici : Développement > MySQL > 2) Indexer les données > c) Une utilisation récurrente pour un bon index
Langue : fr

c) Une utilisation récurrente pour un bon index

Le choix d'un index doit en outre correspondre à une utilisation intensive du champ indexé. Poser un index sur un champ 'age_client' si celui-ci n'est utilisé dans aucune clause JOIN, WHERE, GROUP BY ou ORDER BY de vos requêtes ne présente par exemple absolument aucun intérêt, à moins d'avoir un sens de l'humour très particulier (et encore).

En revanche, si vous faites beaucoup de requêtes par rapport à un champ 'id_notaire' (si les dossiers des clients sont traités par rapport à la zone géographique du notaire qui les traite, par exemple), vous avez tout intérêt à l'indexer s'il répond également au critère de forte cardinalité (c'est-à-dire, si tous vos clients n'utilisent pas les services du même notaire).

Il est cependant inutile de poser plusieurs index sur des champs qui sont toujours sélectionnés de façon commune. En effet, MySQL n'utilise jamais plusieurs index pour une requête sur une même table, mais sélectionne le plus performant, c'est-à-dire celui qui retourne le plus petit nombre d'enregistrements. Ainsi, si toutes vos requêtes utilisent systématiquement deux champs indexés 'id' et 'id_pere' et que c'est toujours le même champ qui retourne le nombre de résultats le plus faible, vous pouvez légitimement supprimer l'un des deux index redondant.

Au niveau technique, l'utilisation d'un index unique s'explique très facilement en se remémorant le fait que le processus d'indexation consiste en l'ordonnancement des données dans un arbre binaire de recherche. Parcourir plusieurs arbres ne serait pas très efficace.

  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