Poblème de performances

[genio]

Bonjour les forumistes...

Un SELECT imbriqué lit une table de 20000 rows en 'table acces Full' pourtant l'identifiant utilisé pour lire cette table est la clé de la table...(Oracle préfère donc lire en 'table acces full' et je ne sais pas pourquoi...)
ALors, j'ai simulé (avec DBMS-STATS.set_colums_stats, et DBMS-STATS.set_colums_index) un index à 5000000 rows et la colonne indéxée avec 500000 valeurs différentes) =>

Et bien ça ne change rein à mon Explain.. la table est toujours lue en 'Table acces full'...
Ai-je oublié quelque chose ? Faut-il faire autre chose ?

Merci pour vos aides ...

[McM]

Faudrait voir la requete.
Pas de cast implicite sur une des colonnes ?

[genio]

Qu'appelez-vous 'cast implicite', un hint caché quelque part ? Ce n'est pas le cas...

[SheikYerbouti]

Il y a t-il seulement une clause WHERE déterminante dans l'ordre Select ?

[McM]

Cast implicite : dans ta table une colonne col1 : NUMBER,
tu lui passes WHERE col1 = '0'

[genio]

Bien sûr, ma clause where est codée avec :
WHERE
CODE_autre_table = CODE_ma_table

en fait, l'optimiseur prend l'index de code_autre_table et lis cette autre_table d'une façon qui ralentit le traitement...
Comment faire pour que l'optimiseur choisisse l'index de CODE_ma_table...

Merci encore pour vos réponses...

[McM]

ajoute un HINT

Code :

SELECT /*+ INDEX (Nom_ou_alias_table nom_index)*/

Mias normalement il se débrouille tout seul.

[SheikYerbouti]

Je me souviens avoir vu des problèmes de perfs parceque les colonnes jointes n'étaient pas de même type

tab1.col1 = tab2.col1

tab1.col1 était Varchar2
tab2.col1 était number