Le coût de maintenance d'un index (mono-colonne ou multi-colonnes) est presque toujours compensé par l'amélioration des performances lorsque cet index est utilisé. C'est un petit incrément sur chaque INSERT /DELETE , plus un coût si la modification de la valeur d'un champ indexé via UPDATE . (La UPDATE cas est rare.) Alors, ne vous inquiétez pas du coût de "maintenir un index composé".
WHERE `vehicles`.`type` IN ('Car')
AND `vehicles`.`user_id` = 10
nécessite INDEX(user_id, type) .
L'optimiseur va
- découvrir que cet index est un candidat possible,
- vérifiez quelques statistiques, puis
- soit utiliser l'index, soit décider que la cardinalité est mauvaise et parcourir simplement la table.
Inclure l'index ; ne vous inquiétez pas.
J'ai ordonné les champs de cette façon, pas (type, user_id) en fonction de votre IN , ce qui implique que vous pouvez parfois avoir plusieurs valeurs pour type .
Si toutes les lignes du tableau ont type = 'Car' , aucun problème. Tout ce que j'ai dit s'applique toujours. Le gaspillage d'inclure le type inutile est insignifiant.
Il est préférable d'avoir toutes les colonnes "=" en premier dans un index, puis au plus un autre champ. Plus de discussion ici .
