La première chose à savoir est que MySQL n'utilise qu'un seul index par pseudo-SELECT (pas d'instruction) - lorsque vous affichez la sortie du SELECT en utilisant EXPLAIN, vous verrez quel index a été choisi. EXPLAIN ne peut être exécuté que sur SELECTS, nous devons donc supposer qu'un DELETE/UPDATE utilise le même plan lorsque vous échangez la syntaxe pour SELECT...
À ma connaissance, la plupart des bases de données (celles intégrées peuvent être étranges) prennent en charge l'utilisation d'index dans les clauses suivantes :
- SÉLECTIONNER
- JOIN (syntaxe ANSI-92)
- WHERE (parce qu'il y a à la fois ANSI-89 et filtrage ici)
- HAVING (WHERE équivalent, mais contrairement à WHERE - permet une utilisation agrégée sans avoir besoin de sous-requête)
- TRIER PAR
Je ne suis pas à 100 % sur GROUP BY, donc je l'omets pour le moment.
En fin de compte, c'est le choix des optimiseurs pour ce qu'il faut utiliser en fonction de son algorithme et des statistiques dont il dispose. Vous pouvez utiliser la syntaxe ANALYZE TABLE pour rafraîchir les statistiques (périodiquement, pas constamment s'il vous plaît).
Avenant
MySQL limite également la quantité d'espace pour allouer des index - 1 000 octets pour les tables MyISAM et 767 octets pour les tables InnoDB . Parce que MySQL n'utilise qu'un seul index par pseudo-SELECT, couvrir les index (index qui incluent plus d'une colonne) est une bonne idée, mais il s'agit vraiment de tester la requête la plus courante et de l'optimiser du mieux que vous pouvez. La priorité d'indexation doit être :
- Clé primaire (quelque part dans la v5, la création d'index pour le pk est devenue automatique)
- Clés étrangères (prochain candidat JOIN le plus probable
- Critères de filtrage (en supposant que vous disposiez de l'espace)
