Optimisation : Utilité de rappeler les derniers champs d'une clé composite ? [Résolu]

[StringBuilder]

Bonjour,

Je suis chez un client, et je fait des évolutions dans des vues.
J'en profite pour remettre de l'ordre aussi, et virer les lourdeurs de conceptions des requêtes.

J'ai une table dont voici la structure :

matable (id1, id2, id3, id4, val1, val2, val3, ...)

En souligné la clé composite de la table.

Chez ce client, le paramétrage (immuable pour cette partie applicative) fait que id1 et id2 sont suffisants pour identifier une ligne. id3 et id4 sont toujours à 0, quelles que soient les valeurs de id1 et id2.

La requête est donc écrite avec une jointure sur la table qui ne teste que id1 et id2.
=> Il en résulte dans le plan d'exécution un RANGE SCAN de l'index unique.

Est-ce réellement intéressant de rajouter dans la jointure "id3 = 0 and id4 = 0" afin d'expliquer à Oracle qu'on cherche une unique ligne dans la jointure ?

C'est ce que j'ai fais (pour le fun, au cas où un jour, le paramétrage immuable ne change), mais je me pose la question...

A l'exécution je n'ai pas de différence perceptible.

[LBO72]

Bonjour,

As-tu modifié ton index pour qu'il ne porte plus que sur id1 et id2 ?

Cdlt,
LBO72.

[StringBuilder]

Non, ça c'est pas possible.

Il s'agit d'un ERP, donc je ne peux pas modifier ni le modèle des données, ni les index standard.

Du coup je dois trouver la solution la plus performante en conservant cette structure.

De plus, la table sert à plusieurs choses, et d'autres entités utilisent la totalité de la clé.

[laurentschneider]

Envoyé par StringBuilder

Est-ce réellement intéressant de rajouter dans la jointure "id3 = 0 and id4 = 0" afin d'expliquer à Oracle qu'on cherche une unique ligne dans la jointure ?

Je dirais que oui, ça te permet de passer du RANGE SCAN à l'UNIQUE SCAN

Code :

1
2
3
4
5
6
7
8
9
10
11
SQL> SELECT * FROM t WHERE id1=1 AND id2=1
 
       ID1        ID2        ID3        ID4       VAL1       VAL2       VAL3
---------- ---------- ---------- ---------- ---------- ---------- ----------
         1          1          0          0          1          1          1
 
Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=4 Card=1 Bytes=21)
   1    0    TABLE ACCESS BY INDEX ROWID T (Cost=4 Card=1 Bytes=21)
   2    1      INDEX RANGE SCAN SYS_C0032014 (Cost=3 Card=1)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
SQL> SELECT * FROM t WHERE id1=1 AND id2=1 AND id3=0 AND id4=0
 
       ID1        ID2        ID3        ID4       VAL1       VAL2       VAL3
---------- ---------- ---------- ---------- ---------- ---------- ----------
         1          1          0          0          1          1          1
1 row selected.
 
Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=3 Card=1 Bytes=21)
   1    0    TABLE ACCESS BY INDEX ROWID T (Cost=3 Card=1 Bytes=21)
   2    1      INDEX UNIQUE SCAN SYS_C0032014 (Cost=2 Card=1)

[StringBuilder]

C'est effectivement ce que je me suis toujours dit (et ce que j'applique habituellement). Au détail près que niveau performances, je n'ai jamais vu de différence.

Ceci dit, comme je disais "au cas où" le paramétrage changerait, je pense qu'il est de toute façon plus prudent de remettre tous les champs de la clé, ça évitera d'avoir une démultiplicatin des lignes si un jour on se retrouve avec id3 ou id4 != 0...

[mnitu]

Envoyé par StringBuilder

C'est effectivement ce que je me suis toujours dit (et ce que j'applique habituellement). Au détail près que niveau performances, je n'ai jamais vu de différence.
...

Il est difficile de mettre en évidence l’effet ou il faut un test avec beaucoup des lectures. Dans le cas A) Oracle va lire le block racine de l’index va descendra ensuite jusqu’au block qui contient la clé (id1, id2, id3, id4) et ensuite va parcourir les ensembles des clés (id1, id2, X, Y). Mais comme id3 et id4 ont une seule et unique valeur 0 cela est assez proche du cas B) où Oracle descend l’index via la racine jusqu’au la clé unique cette fois (Id1, id2, id3, id4)