Utilisation des index (dans une clause WHERE)

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

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.

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)

Citation:

---

Envoyé par punkoff

(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.

8-)

JJE

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.

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.

8-)

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 ;).

Index est invariable en français : un index, des index.
Indexes est le pluriel anglais !

Vous l'écriviez bien... au début ! ;)

Citation:

---

Envoyé par Waldar

Index est invariable en français : un index, des index.
Indexes est le pluriel anglais !

Vous l'écriviez bien... au début ! ;)

---

D'accord :mrgreen: !

Je croyais avoir retrouvé mon français, mais non, l'anglais me poursuit...

Autant pour moi !

8-)

JJE

Salut !

Sur Oracle aussi, on fait de l'index join sans bitmap, on a même un petit article sur le site :
http://blog.developpez.com/pachot/p8...fp-index-join/

Sinon pour le reste, la stratégie d'indexation dépend de plein de trucs dont le cas d'utilisation. L'intérêt d'avoir un index composite sur les 6 colonnes serait de le rendre couvrant et éventuellement d'économiser un accès table.
Par contre, augmenter la taille de l'index, ça alourdit les "large scans"... du coup si tu récupères peu de lignes, tu peux vouloir juste trouver la combinaison "suffisamment sélective"...

A lire : Que faut-il indexer ?

A +

Ola,

Merci pour toutes vos réponses et en particulier à celle de SQLPro : ce lien répond à toutes mes questions.

:ccool:

JJE

Hi,

Je réouvre le post pour une dernière question :

L'ordre dans lequel sont énumérées les conditions dans la clause WHERE a-t-il de l'importance ? En d'autres temres, vaut-il mieux placer comme première condition celle qui dispose d'un index utilisable (ou qui est la plus sélective) ?

Autre manière de formuler la question, les SGBD sont-ils suffisament intelligents que pour optimiser l'ordre des conditions à tester dans la clause WHERE ?

Merci

8-)

JJE

Je ne saurais me prononcer pour Caché, mais les gros SGBD du marché ont des optimiseurs qui s'appuient sur des statistiques et choisissent en fonction de ces dernières la meilleure façon d'accéder aux données.