Discussion :

[Drizzt [Drone38]]

Bonjour,

J'ai une requete très simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT champs1, champs2, champs3 
FROM table
WHERE champs1 in ('A','B') and champs1 <> 'C'

Je possède un index1 sur champs1 et un index2 sur (champs2, champs1) dans cet ordre.

En exécutant la requête comme cela, Oracle me fait un table access full.
Si je modifie la requete en supprimant champs3 du select, Oracle utilise l'index sur (champs2, champs1).

Question :
- Quelle(s) pourrai(en)t être la ou les raisons de la non utilisation de l'index1 dans le premier cas ?
- Idem dans le second cas, pourquoi utilise-t-il index2 qui début par un champs non présent dans la clause where ?

Pour information, la table possède d'autres champs ainsi que d'autres indexs ne commençant ni par champs1 ni par champs2.
De plus ce problème ne se produit pas sur mon environnement de dev qui lui ne possède que les index1 et 2.

Edit> J'ai supprimé les indexs autres que le 1 et 2 sur la base ou j'ai le problème, et ce dernier persiste.

Merci d'avance.

[orafrance]

- Quelle(s) pourrai(en)t être la ou les raisons de la non utilisation de l'index1 dans le premier cas ?

le champs1 <> 'C' doit poser problème, peut-être trop de lignes ramenées.

- Idem dans le second cas, pourquoi utilise-t-il index2 qui début par un champs non présent dans la clause where ?

parce que l'index contient toutes les colonnes utilisées dans la requête et permet ainsi d'économiser une TABLE ACCESS
Quitte à faire un accés disque autant taper dans l'index directement plutôt que faire un FTS.

Imaginons que la requête retourne 80% des lignes de la table. Dans le 1° cas, il faut faire un accés à la table pour récupérer champs3 mais comme on récupère bcp de données l'usage de l'index n'est pas intéressant. Dans le 2° cas, plus besoin d'aller dans la table donc autant utiliser l'index, même s'il n'est pas super intéressant, il l'est forcément plus qu'un FULL sur la table

[Drizzt [Drone38]]

Ok je comprends mieux !

Merci