[Oracle 9.2.0.1.0]Infos générales pour indexation. [Résolu]

[marchand_de_sable]

Bonjour à tous.

Je travaille actuellement à l'optimisation d'une base, et revois donc le plan d'indexation existant. Plus précisément, j'ai une table de plus 80 millions de ligne (35 Go) et qui grandit rapidement, et pénalise énormément mes requêtes.
Elle "contient" actuellement 9 index, portant sur 15 champs en tout. D'après ce que j'ai pu trouver sur le sujet, tous ces index risquent de ne rien améliorer, voir même de pénaliser encore plus les performances...

Pour cette table, je pense me focaliser sur l'indexation de 3 à 5 champs maximum. Quelques questions :
1) Quelle différence entre 1 index portant sur X champs, et X index portant sur chacun des champs ?
2) J'ai 3 champs que je voudrait plus particulièrement indexer. Le tableau suivant présente pour une valeur de champ_X, le nombre moyen de valeurs différentes des 2 autres champs :

Code :

1
2
3
4
5
6
7
Champ_1 | Champ_2 | Champ_3 |
-------------------------------
     1  |   400   |     30  |
60 000  |     1   |     60  |
30 000  |   400   |      1  |
-------------------------------
60 000  |   400   |    60   | => Nb de valeurs différentes par champ

J'imagine qu'on indexe d'abord les plus restrictifs. Du coup, je dirais qu'il faut indexer champ_1, puis champ_2, et enfin champ_3. Qu'en pensez-vous ?

3) Question subsidiaire : comment relancer le calcul d'un index particulier ??

Merci d'avance de partager vos lumières !!

[dgi77]

1) 1 index portant sur X champs n'est pris que si un critère est fourni dans la clause WHERE à partir du premier champ, sinon il est zappé.
Par exemple, soit un index sur (champ1, champ2, champ3).
Si une requête faire un WHERE champ2 = ... AND champ3 = ... , l'index ne sera pas pris car son point d'entrée champ1 n'est pas spécifié.
Si par contre on a un WHERE champ1 = ... AND champ2 = ... , l'index sera pris jusqu'à champ2.
Il n'est donc pas incohérent qu'une colonne figure à la fois dans un index monocolonne et dans un index multicolonne (à condition qu'elle ne soit pas en première position, sinon aucun intérêt).

2) Je ne comprends pas trop les résultats du tableau, mais c'est clair qi'il faut commencer par indexer les champs les plus restrictifs, c'est-à-dire ceux qui ramèneront le moins de combinaisons des autres champs.

3) ALTER INDEX nom_index REBUILD
(voir doc. pour les options)

[marchand_de_sable]

1) 1 index portant sur X champs n'est pris que si un critère est fourni dans la clause WHERE à partir du premier champ, sinon il est zappé.

Et si le 1er champ entre dans une jointure type OUTER JOIN ... ON mon_champ_indexé_en_1er=un_autre_champ, ça marche ?
(Je sais, la question est bizard vu que cela sous entend que mon champ entre dans la définition d'une clé, et donc indexé...sauf que ça pourraît m'arranger de supplanter ces index de clé).

2) Je ne comprends pas trop les résultats du tableau

La 1ère ligne signifie que pour 1 valeur de champ_1, on aura en moyenne 400 valeurs distinctes de champ_2 et 30 valeurs distinctes de champ_3. Ligne 2 : pour 1 valeur de champ_2, j'aurais 60 000 valeurs distinctes de champ_1 et 60 valeurs distinctes de champ_3. Etc.

3) ALTER INDEX nom_index REBUILD
(voir doc. pour les options)

OK.

Merci pour ces réponses !

[dgi77]

1) Oui, je pense que l'index sera pris.

2) OK, donc il faut bien indexer dans l'ordre de priorité que tu as donné au début (champ1, puis champ2, puis champ3)

[marchand_de_sable]

OK. Encore merci pour tes réponses.
J'en ose une petite dernière....

2) OK, donc il faut bien indexer dans l'ordre de priorité que tu as donné au début (champ1, puis champ2, puis champ3)

Là on parle bien d'un index portant sur les 3 champs ?

[dgi77]

Oui, d'un point de vue technique, encore faut-il vérifier que ça colle d'un point de vue fonctionnel (je veux dire que ce champ soit critériser au moins aussi souvent que les suivants).

Mais c'est également valable pour un index monocolonne : si tu ne dois en créer qu'un, c'est celui-là, ce sera le plus performant, en pensant toujours à l'utilité fonctionnelle.

[marchand_de_sable]

Envoyé par dgi77

Oui, d'un point de vue technique, encore faut-il vérifier que ça colle d'un point de vue fonctionnel

J'y avais pensé... A quoi bon indexé un champ dont on ne se sert pas ???

Encore merci pour toutes ces infos.

A+