par
Ryle » 28 mars 2007, 00:21
Le but de l'index, comme son nom le laisser présager, c'est d'indexer les éléments de ta table, pour faciliter la recherche de ces éléments (comme dans un bouquin, tu consultes l'index, ca te donne la page, c'est plus rapide pour trouver ce que tu cherches).
Il faut donc indexer les choses que sur lesquelles tu vas avoir régulièrement besoin de faire des recherches (si on listait dans un bouquin toutes les pages qui contiennent "le", "la" ou "les" on en finirait pas de lire l'index
)
L'idéal est donc effectivement d'indexer les champs qui sont le plus solicités dans tes critères de sélection (la clauses WHERE donc, comme le signale
AB) ... il y a toutefois quelques exceptions
Inutile par exemple d'indexer une clé primaire, l'indexation en est imlicite
Inutile également d'indexer un champ sur lesquel tu ne fais pas de recherche exacte. Si ta condition est un LIKE, l'index ne servira à rien, toute la table sera parcourue pour retrouver la chaine correspondante, juste au cas où, même si c'est un index. (d'où les soucis de performance d'un LIKE)
Tu peux également utiliser des index composés si tes critères portent sur une même liste de champs. Par exemple avoir un index composé des colonnes a, b et c augmentera la vitesse de sélection sur une requête de type : "WHERE a = ... AND b = ... AND c = ... ". Idem si la requête est juste "WHERE a = ... AND b = ... " ou "WHERE a = ... ", cet index conviendra et sera plus efficace qu'un index sur chaque champ.
En revanche, cet index ne conviendrait pas si tu as parfois des critères du type "WHERE b = ... AND c = ... " ou "WHERE c = ... ". Il faudrait alors en plus indexer "b et c" et "c", voire juste "c et b" (l'ordre dans l'index est donc important) pour que ces requête en profite aussi.
Enfin, dernière chose, ajouter un index améliore la vitesse d'exécution des SELECT, mais il ne faut pas oublier que la base doit mettre à jour ses index à chaque update ou insert, les rendant donc un chouilla plus lent. Si une table reçoit chaque jour un nombre plus conséquent d'insert que de select, on va avoir tendance à éviter d'y mettre des index pour gagner en rapidité d'écriture, au détriment de la lecture
HTH
Le but de l'index, comme son nom le laisser présager, c'est d'indexer les éléments de ta table, pour faciliter la recherche de ces éléments (comme dans un bouquin, tu consultes l'index, ca te donne la page, c'est plus rapide pour trouver ce que tu cherches).
Il faut donc indexer les choses que sur lesquelles tu vas avoir régulièrement besoin de faire des recherches (si on listait dans un bouquin toutes les pages qui contiennent "le", "la" ou "les" on en finirait pas de lire l'index ;))
L'idéal est donc effectivement d'indexer les champs qui sont le plus solicités dans tes critères de sélection (la clauses WHERE donc, comme le signale [b]AB[/b]) ... il y a toutefois quelques exceptions :)
Inutile par exemple d'indexer une clé primaire, l'indexation en est imlicite :)
Inutile également d'indexer un champ sur lesquel tu ne fais pas de recherche exacte. Si ta condition est un LIKE, l'index ne servira à rien, toute la table sera parcourue pour retrouver la chaine correspondante, juste au cas où, même si c'est un index. (d'où les soucis de performance d'un LIKE)
Tu peux également utiliser des index composés si tes critères portent sur une même liste de champs. Par exemple avoir un index composé des colonnes a, b et c augmentera la vitesse de sélection sur une requête de type : "WHERE a = ... AND b = ... AND c = ... ". Idem si la requête est juste "WHERE a = ... AND b = ... " ou "WHERE a = ... ", cet index conviendra et sera plus efficace qu'un index sur chaque champ.
En revanche, cet index ne conviendrait pas si tu as parfois des critères du type "WHERE b = ... AND c = ... " ou "WHERE c = ... ". Il faudrait alors en plus indexer "b et c" et "c", voire juste "c et b" (l'ordre dans l'index est donc important) pour que ces requête en profite aussi.
Enfin, dernière chose, ajouter un index améliore la vitesse d'exécution des SELECT, mais il ne faut pas oublier que la base doit mettre à jour ses index à chaque update ou insert, les rendant donc un chouilla plus lent. Si une table reçoit chaque jour un nombre plus conséquent d'insert que de select, on va avoir tendance à éviter d'y mettre des index pour gagner en rapidité d'écriture, au détriment de la lecture :)
HTH
