Bonjour,
Je m'intéresse actuellement aux plans d'exécution sous Oracle. Malheureusement, quelque chose m'échappe.
Imaginons le schéma suivant :
Table1(attribut1_pk, attribut2)
Table2(attribut3, attribut4, #attribut1_fkey)
On suppose donc avoir un index sur les clés primaires et sur l'attribut de jointure table2.attribut1_fkey.
J'exécute la requête suivante :
J'obtiens alors le plan d'exécution suivant :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 select attribut4 from table1 natural join table2
Le CBO choisit donc une jointure par Merge Join. Comme je récupère l'attribut 4, je ne peux pas me contenter de faire un Index Full Scan sur la table 2, comme pour la table 1. Jusque là, je comprends.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 --------------------------------------------------------------- --| Id | Operation | Name | Rows | --------------------------------------------------------------- --| 0 | SELECT STATEMENT | | 48 | --| 1 | MERGE JOIN | | 48 | --| 2 | TABLE ACCESS BY INDEX ROWID| TABLE2 | 81 | --| 3 | INDEX FULL SCAN | I_TABLE2 | 81 | --|* 4 | SORT JOIN | | 48 | --| 5 | INDEX FULL SCAN | PK_TABLE | 48 | ---------------------------------------------------------------
Ce qui me gêne concerne les opérations 2 et 3, c'est-à-dire l'utilisation conjointe d'un Index Full Scan et d'un Table Access By Rowid. Quel est l'intérêt de faire un Index Full Scan, qui va retourner les rowid de toutes les lignes, puis ensuite d'accéder à tous ces Rowid un par un ? Ne serait-il pas plus pratique de faire un Table Access Full directement ?
Autre hypothèse : je me trompe et les Table Access By Index Rowid ne concernent que les lignes qui auront été jointes à l'aide des deux index ? Auquel cas, ces opérations me choqueraient moins.
Merci d'avance pour les éclaircissements.
Partager