Discussion :

[Jean-Jacques Engels]

Bonjour,

Voici ma question :

J'ai entendu dire que, dans une clause WHERE portant sur (disons) 6 champs indexés, un seul des 6 index était réellement utilisé par le SGBD. Donc, après avoir opéré une première sélection d'enregistrements sur base d'un des index (lequel ?), le moteur parcourerait ensuite séquentiellement ce résultat intermédiaire pour opérer sa sélection finale. Il n'utiliserait donc plus aucun autre index dans sa sélection finale.

Est-ce exacte ? Ou bien cela dépend-t-il du sgbd ?

La question sous jacente est la suivante : j'utilise un query avec une clause WHERE qui porte sur 6 champs et je constate que cela rame. Je sais que sur la moitié des champs de la clause WHERE il existe un index, pas sur les autres. Cela vaut-il la peine de créer les indexs manquant, ou est-ce inutile vu les doutes soulevés par ma première question ?

Merci.

JJE

[Waldar]

Tout-à-fait, une table n'utilisera au mieux qu'un seul index B*Tree.

Il existe des index bitmap qui sont combinables, mais ils ne sont disponibles que sur peu de SGBD et ont des spécificités d'utilisation.

Indexer vos colonnes une à une n'a de sens que si vous avez des accès à votre table par ces colonnes unitairement.

Par contre, un index peut porter sur vos six colonnes, et le temps de réponse de votre requête sera à coup sûr grandement amélioré.

Toutefois n'oubliez pas qu'un index n'est pas gratuit : il a un coût de construction, de maintenance, d'espace disque.
Il faut mettre ces éléments aussi dans la balance.

[punkoff]

Bonjour,

J'emetrai quand même une nuance sur ce que dit Waldar (ou alors j'ai mal compris ce que tu as dis).

A partir d'index b*tree un sgbd peut très bien engendrer une comparaison de type bitmap.

De ce fait en disposant de plusieurs index sur des colonnes uniques, le sgbd peut être amené à utiliser ces différents index et les recouper (par exemple sous postgesql ou db2 system i)

[Jean-Jacques Engels]

(par exemple sous postgesql ou db2 system i)

Donc, cela pourrait quand même dépendre du SGBD...
Nous travaillons sous Caché de chez Intersystems. Un truc bizarre dont je n'avais jamais entendu parler jusqu'à ce que j'arrive chez mon nouvel employeur.
Je vais me renseigner plus avant chez mon DBA.

Merci pour vos réponses.



JJE

[Rei Ichido]

Même si le SGBD peut se dépatouiller, ça va lui demander de faire des opérations assez coûteuses (a priori il ne le fera que s'il escompte un gain, mais bon).
=> Un index portant sur plusieurs champs sera nettement plus efficace, l'ordre étant important. Idéalement, il faut placer le champ le plus sélectif en premier, mais il faut aussi tenir compte de l'ensemble des requêtes formulées pour avoir un index le plus utilisable possible.

[Jean-Jacques Engels]

En fait, pour corser le tout, il faut savoir que la clause WHERE de mon query est construite dynamiquement en fonction de paramètres que l'utilisateur introduit à son écran. Et donc, l'application ne sait pas à l'avance de quoi sera constituée cette clause WHERE. Il se peut que celle-ci agisse sur un seul champs tout comme il est possible qu'elle agisse sur une combinaison allant de 2 à 6 champs. Tout est donc fonction des résultats souhaités par l'utilisateur.

Donc, nouvelle question : ai-je intérêt à créer 6 indexes (un sur chaque champ) ou ai-je intérêt à construire un seul indexe qui inclut les 6 champs ? Dans cette dernière hypothèse, est-ce que l'ordre des champs dans cet indexe a de l'importance ?

Merci.



JJE

PS : avez-vous remarquez que je m'étais documenté entre-temps sur la manière d'écrire le mot "indexe" ainsi que son pluriel. A force d'utiliser l'anglais en informatique, on y perd un peu son français .