Discussion :

[ViRouF]

Bonjour,


Est-il stupide de créer un index "unitaire" (sur un champs seulement), qui compose la clé primaire d'une table et qui est donc déjà indexé mais couplé avec d'autres champs ?

Si oui, est-ce le cas quelque soit son positionnement dans la clé primaire (début, milieu ... fin) ?


Merci à vous,

ViRouF

[SQLpro]

Que voulez-vous dire par couplé ? Avez vous un exemple ??

A +

[ViRouF]

Que voulez-vous dire par couplé ? Avez vous un exemple ??

A +

Relation R (champ1, champ2, champ3, ...)

Est-il utile, ou complétement con de vouloir créer un index sur champ2 par exemple ?

Car je me retrouve dans le cas où, sur SAP (basé sur du oracle 9) j'ai une table de 30 millions d'enregistrement et je dois en extraire une partie en faisant une restriction sur seulement une partie de la clé.

Vu le temps que ça prend je cherche des solutions

Merci

[denverdba]

D'abbord, pardon mes erreurs. Je suis Americain et mon francais ne pas tres bien. J'apprends encore le français et j'apprécions des corrections.

Si vous avez un index dans champ1, champ2, champ3, et vous faire SQL comment <<select * from table where champ2='ABC'>> Oracle ne pas utilise ce index.

Pour ce SQL vous avez besoin de un index avec champ2 premier. Peut-etre comment champ2, champ3, et ca. Vous devait toujours utilisez le premier colonne dans votre index dans votre SQL.

J'espère que vous pourrez me comprendre.

[ViRouF]

D'abbord, pardon mes erreurs. Je suis Americain et mon francais ne pas tres bien. J'apprends encore le français et j'apprécions des corrections.

Si vous avez un index dans champ1, champ2, champ3, et vous faire SQL comment <<select * from table where champ2='ABC'>> Oracle ne pas utilise ce index.

Pour ce SQL vous avez besoin de un index avec champ2 premier. Peut-etre comment champ2, champ3, et ca. Vous devait toujours utilisez le premier colonne dans votre index dans votre SQL.

J'espère que vous pourrez me comprendre.

Ok je vous ai compris
Quelqu'un pour confirmer ?

[orafrance]

je confirme :

SQL>create table matable (col1 number, col2 number);

Table created.

SQL>create index monind on matable(col1,col2);

Index created.

SQL>set autotrace on exp
SQL>select * from matable where col2 = 1;

no rows selected


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'MATABLE'



SQL>select * from matable where col1=1;

no rows selected


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 INDEX (RANGE SCAN) OF 'MONIND' (NON-UNIQUE)

A ceci prêt qu'un simple changement de l'ordre des colonnes suffit à régler ce souci :

SQL>drop index monind;

Index dropped.

SQL>create index monind on matable(col2,col1);

Index created.

SQL>select * from matable where col2 = 1;

no rows selected


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 INDEX (RANGE SCAN) OF 'MONIND' (NON-UNIQUE)

Il est souvent plus performant de faire un seul index de x colonnes que x indexes de 1 colonne, il convient donc de favoriser les indexes sur plusieurs colonnes en mettant les colonnes qui serviront toujours en 1° et les colonnes facultative après

[ViRouF]

merci beaucoup