d) Gare aux contre-optimisations

L'indexation se traduit physiquement par la création d'un fichier d'index. Plus sa taille est importante, plus son temps de parcours est long. L'amélioration des performances est donc bien meilleure si la taille de l'index est réduit. Si l'utilisation d'un index n'est pas suffisamment discriminante quant aux résultats trouvés (nombre d'enregistrements retournés équivalent à 50 à 30% des enregistrements de la table), l'optimiseur MySQL est susceptible de ne pas l'utiliser.

Enfin, il faut savoir que l'indexation accélère la recherche d'enregistrements, mais ralentit leur insertion et modification, car il faut mettre à jour l'index en plus des données. Sachez donc rester en tout temps pragmatique. Si vos tables ont une activité principale de logs (commande INSERT) et que vous faites un export global des données une fois par jour (commande SELECT), poser des index n'est pas très utile. Mais il faut bien avouer que ce n'est pas l'utilisation la plus répandue d'une base de données. En règle générale, celle-ci est plutôt conçue pour faire beaucoup de SELECT et peu d'INSERT/UPDATE/DELETE, ou alors de façon équivalente.

Concernant l'insertion d'enregistrements de façon massive (ex. insertion de journées d'activité dans une application de planning des salariés), il est plus efficace d'utiliser l'insertion étendue que d'insérer les enregistrements un par un. En effet, outre l'optimisation de la taille du texte envoyé pour la requête (qui ne doit pas dépasser 2Mb toutefois) en évitant les répétitions (on en revient toujours là), l'index est mis à jour seulement à la fin de l'insertion étendue, et non après chaque insert fait de façon séquentielle.