En fait, c’est une question que je me posais depuis longtemps et, même si Google est mon ami, j’ai jamais trouvé la réponse de façon claire .. ni pris le temps d’investiguer ou de faire des tests (honte à moi !!).

Sinon, pour compléter un oubli sur mon commentaire précédent, je reprends Collobian à propos du post : “Excellent, et salutaire.”

effectivement la série n’est pas terminée mais pour répondre à ta question, il faut considérer que sauf cas particulier (voir “index merge optimization” dans la doc / présence de “index_merge” dans la colonne “type” de EXPLAIN), MySQL n’utilise qu’un seul index à la fois. Donc soit celui-ci est multiple, auquel cas tu tombes dans le comportement évoqué plus haut avec le leftmost prefixing, soit tes index sont posés séparemment et dans ce cas (sauf index_merge encore une fois) MySQL, et plus précisemment l’optimiseur, va choisir l’index le plus efficace c’est à dire le plus restrictif, autrement dit celui qui permet d’éliminer le plus de tuples le plus rapidement possible.
On ne maîtrise pas vraiment les choix de l’optimiseur sauf à volontairement fournir des données dont on sait qu’elles vont le conduire à prendre telle ou telle décision, des commandes existent également pour le forcer à choisir un index en particulier et pas un autre, il est aussi possible de le contraindre à effectuer une jointure dans un ordre précis mais ces commandes sont à manier en connaissance de cause, elles seront évoquées dans un prochain billet.

“Les champs concernés par une clause WHERE, ORDER BY, GROUP BY, MIN(), MAX(),
ainsi que les champs qui permettent de relier des tables entre elles”

Si un requête contient plusieurs clauses, chacune ayant un index. Quels seront les index utilisés ? Tous ? Dans que ordre seront-ils utilisés ? Par rapport à la clause ou par rapport à l’efficacité de l’index ?

En ce qui concerne ton tips, a.id = b.id ou b.id = a.id, l’optimiseur va résoudre cette jointure selon ses calculs, il ne va donc pas forcément faire intervenir les tables selon l’ordre dans lequel elles ont été écrites (l’ordre finalement retenu est indiqué dans le EXPLAIN), je pense donc que sur ce point tu évoques sans doute le query cache ? Dans ce cas oui effectivement, si a.id = b.id est déjà dans le cache, autant en profiter et ne pas demander la même chose mais exprimé différemment.

A propos du second point, le cas où il y’a “plusieurs tests”, je pense que l’on parle ici du leftmost prefixing ? Si c’est bien cela, l’ordre importe effectivement.

Petit tips : dans les requetes, il faut eviter de faire une fois un ‘where a.id = b.id’ puis dans une autre requete ‘where b.id = a.id’, l’ordre influe sur les perfs. Pareil s’il y a plusieurs tests, il faut les mettre dans le meme ordre (celui de l’index en fait).