MYSQL: index pour les conditions where mais pour..

[thierry8]

arf ! salut !


je ne sais plus s'il faut mettre en index un champ utilisé pour un trie (ORDER BY) j'aurais tendance à dire oui, mais je préfère confirmation.

[thierry8]

réponse ici:

http://dev.mysql.com/doc/refman/5.0/fr/ ... ation.html

arf! pas très clair leur truc.

vous utilisez des indexes en règle générale pour ça ?

[dmathieu]

Non, ca n'a pas d'intéret.
Supposons une table contenant des actualités, tu veut trier par le champ date, tu n'aura pas besoin de mettre de clé index sur le champ date.

[thierry8]

ah, mais pourquoi je ne comprend pas pourquoi il n'y a pas d'intérêt..
Ne serait-ce pas plus rapide ?

[bendeg]

Ayant déjà travaillé avec MySQL, il n'est pas nécessaire de spécifier un champ comme étant un index pour la clause "ORDER BY".

Je ne pense pas me tromper en disant que la recherche se fera plus rapidement si le champ est indexé. C'est avantageux surtout pour des tables contenant beaucoup de lignes sinon, laisse tomber, ce n'est pas nécessaire, et le désavantage, c'est que ça prend plus de place en BD.

Les champs indexés avec MySQL ont une autre fonction à part celle consistant à accélérer le recherche, à savoir les contraintes d'intégrité. Si c'est déjà du chinois pour toi, laisse tomber, utilise les index seulement pour accélérer le recherche, une BD fonctionnera très bien sans ces contraintes d'intégrité :

Si un champ fait partie d'une clé primaire composée de plusieurs champs, dans le cas d'une table mère et d'une table fille (un des champs de la table fille faisant partie de la clé primaire de la table fille est une référence à la clé primaire de la table mère), cela peut être pratique : il sera par exemple impossible de supprimer une ligne dans la table mère si, dans la table fille, il existe au moins une ligne qui fait référence à la susdite ligne de la table mère (si cela arrive, MySQL le signale par un message d'erreur et ne modifie rien). Dans ce cas, ce champ (dans la table fille donc) doit non seulement être un index mais doit aussi se trouver dans les premiers champs de la table.

Voilà, j'espère que ça aide

[thierry8]

Merci pour ces précisions supplémentaires, mais tu dis:

- que ce n'est pas la peine..

Ayant déjà travaillé avec MySQL, il n'est pas nécessaire de spécifier un champ comme étant un index pour la clause "ORDER BY".

- mais que c'est quand même plus rapide..

Je ne pense pas me tromper en disant que la recherche se fera plus rapidement si le champ est indexé. C'est avantageux surtout pour des tables contenant beaucoup de lignes sinon, laisse tomber, ce n'est pas nécessaire, et le désavantage, c'est que ça prend plus de place en BD.

[dmathieu]

Eh bien, il dit que ce n'est pas obligatoire, mais que ca améliore la rapidité.

[thierry8]

ben oui d'accord, mais ça je sais que ce n'est pas obligatoire...

je cherche a savoir si pour ce genre de requête il est plus avantageux d'indexer le champ en question ou pas..

[Robinson]

Tout dépend du type de champ, de son utilisation autre, du nombre d'enregistrements de la table, ...etc

Cela peut rendre cette requète plus rapide mais peut en rendre d'autres plus lentes en augmentant le volume de la base.