Discussion :

[Louisa2005]

est-ce que remplacer le NOT IN par NOT EXISTS permet de gagner de la performance? merci d'écrire l'instruction avec NOT EXISTS et quel est le gain obtenu?

Code :

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

1
2
3
4
5
6
select S.DAY_ID, o.Mag_ID, o.mag_desc
from Vtes_ld  s 
     , Mag_dm   o
where s.Mag_KEY = o.Mag_KEY
and S.DAY_ID NOT IN (select T.DAY_ID from Day_dmT where T.YR_ID <= 2009)
and o.Mag_ID = '9595'

[al1_24]

Le remplacement du NOT IN par un NOT EXISTS donne en principe une requête plus performante, qui tentera de s'exécuter comme une jointure et utiliser les index disponibles à cet effet.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT  s.day_id
    ,   o.mag_id
    ,   o.mag_desc
FROM    vtes_ld s
    INNER JOIN
        mag_dm  o
        ON  s.mag_key = o.mag_key
WHERE   o.mag_id  = '9595'
    AND NOT EXISTS 
        (   SELECT  1 
            FROM    day_dm  t 
            WHERE   t.yr_id <= 2009
                AND s.day_id = t.day_id 
        )

PS : Es-tu sur que mag_id est une chaîne ?

[sgora]

NOT EXISTS n'est pas la panacée, le chemin d'accès que prendra Oracle dépend des statistiques présentes sur les objets concernés et des paramétrages de ta base. Par exemple, j'ai vu récemment une requête en NOT EXISTS dériver sur un plen de jointure NESTED LOOPS, alors que le NOT IN nous donnait un HASH JOIN beaucoup plus efficace. Le NOT IN est optimisé depuis la 8i au moins, et peut également donner des plans d'exécutions corrects.

[orafrance]

Le remplacement du NOT IN par un NOT EXISTS donne en principe une requête plus performante

Pas forcément. Ca dépend surtout de la taille du sous-ensemble. Par ailleurs, NOT IN et NOT EXISTS n'ont pas le même comportement alors attention de bien vérifier que ça ne change pas les contraintes applicatives.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
SQL> create table tab_in(id number);
 
Table created.
 
SQL> insert into tab_in values (1);
 
1 row created.
 
SQL> insert into tab_in values (2);
 
1 row created.
 
SQL> insert into tab_in values (3);
 
1 row created.
 
SQL> create table tab_notin(id number);
 
Table created.
 
SQL> insert into tab_notin values (1);
 
1 row created.
 
SQL> insert into tab_notin values (2);
 
1 row created.
 
SQL> insert into tab_notin values (null);
 
1 row created.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SQL> select * from tab_in where id not in (select id from tab_notin);
 
no rows selected
 
SQL> select * from tab_in t1 where not exists (select 1 from tab_notin t2
  2  where t1.id=t2.id);
 
        ID
----------
         3
 
SQL>

[Waldar]

En plus de la réponse d'orafrance, j'ajouterai que les comportements entre NOT IN et NOT EXISTS se rejoignent de plus en plus avec les versions d'Oracle.

En 11g ça donne quasiment toujours le même plan d'exécution, en gardant à l'esprit la différence de comportement sur présence d'un null.

De mon côté, j'utilise NOT IN quand j'ai une petite liste d'id à filtrer, NOT EXISTS quand je traite des plus grosses volumétries. Mais ce n'est pas une règle empirique.

[mongilotti]

merci de marque ce sujet comme résolu.