Discussion :

[cdu]

bonjour,
on me soutient que la recherche ( select....) sur clé partielle ou sur partie de champ indexé est une chose tout à fait prévue et performante.
résultat, on continue à me faire utiliser des champs textes avec des infos concaténées et des recherches sur ces champs. Bon, c'est souvent sur un préfixe, un début de champs textes.
Pour ma part je ne cautionne pas un tel choix, et pense que cela peut-être cause de problème de performance.

Je me trompe peut-être et en tout cas je n'ai aucun document pour étayer ma position, qu'en pensez vous? :

[rouardg]

on me soutient que la recherche ( select....) sur clé partielle ou sur partie de champ indexé est une chose tout à fait prévue et performante.

C'est vrai, mais il faut que l'ordre des colonnes soit bien pensé.

Par exemple, poser un index sur 3 colonnes A, B et C dans cet ordre fait que, jusqu'à Oracle 8i, cet index sera utilisé si les colonnes sont interrogées dans l'ordre.

En clair, un select sur A, ou sur A et B, ou sur A, B et C fait que l'index sera utilisé (si il est assez sélectif).

Par contre, jusqu'à 8i, si ton select porte sur B, ou sur C, ou sur B et C, l'index ne sera pas utilisé. Il faut en fait interroger l'index en commençant par sa colonne leader (la colonne en entête si tu préfères).

Maintenant, à partir de 9i, ce n'est plus forcément vrai. Oracle a introduit une nouvelle utilisation de l'index qui s'appelle le 'Skip Scanning' et qui fait que, sous certaines conditions, l'index peut être utilisé sans pour autant l'attaquer par sa colonne leader.

résultat, on continue à me faire utiliser des champs textes avec des infos concaténées et des recherches sur ces champs. Bon, c'est souvent sur un préfixe, un début de champs textes.

Il faut faire attention à certaines choses comme l'utilisation de fonctions SQL (ou de fonctions PL/SQL que tu as écrit), la concaténation de champs, la recherche par le LIKE, ou encore la conversion implicte de type de données qui font que l'index n'est plus utilisé. Parfois, on s'en sort en créant un index basé sur une fonction.

Pour ma part je ne cautionne pas un tel choix, et pense que cela peut-être cause de problème de performance.

Le mieux, c'est de faire des essais : il faut tracer les plans d'exécution des requêtes et voir si les index sont utilisés ou non.

[phig]

Bonjour,

Je laisserai l'explication théorique aux spécialistes, pour ma part je vais juste donner quelques exemples.

Code :

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

Select * from <ma_table> where Substr(<mon_champs>, i, j)= 'ma_valeur'

va provoquer un table acces full, sauf si un Index de fonction est défini avec le Substr.

Code :

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

Select * from <ma_table> where <mon_champs> like 'ma_valeur%"

permettra d'utiliser l'éventuel index mais en Range Scan

Code :

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

Select * from <ma_table> where <mon_champs> like '%ma_valeur"

fera un table access full à caus du % au début.
Donc, à moins de définir des index de fonction pour tous les 'sous-champs', on ne passera jamais par un index unique scan (le plus performant)
Personnellement, je vais largement dans votre sens en privilégiant les colonnes pour chaque champs plutot que des concaténations dans une colonne unique.
Le plan d'exécution de vos requêtes devrait vous en dire plus.

Phig

[SheikYerbouti]

Tout en gardant à l'esprit que ce n'est pas parce qu'un index existe qu'il sera forcément utilisé par l'optimiseur.

[Shai_Hulud]

Question Idiote

Qu'appellez vous Plan d'Execution ?

[rouardg]

Le plan d'exécution t'indique comment la requête à été traité par l'optimiseur.

Imagine que tu fasses un select avec jointure sur plusieurs tables.

Alors le plan d'exécution t'indique en gros 3 choses :
- si les données ont été lues directement en table, ou bien si on est d'abord passé par un index (auquel cas, tu as le nom de l'index),
- comment se sont effectués les jointures entre tables, sachant qu'il y a 3 méthodes pour résoudre une jointure : Hash Join, Nested Loop et Sort Merge Join,
- l'ordre dans lequel tout cela s'est fait.

[Shai_Hulud]

Merci à toi .
Très intéressant tout ca, je vais me faire insulter si je demande où trouver une doc la dessus ? ( Oracle 8i )

[rouardg]

Sous ton Oracle Home, va sous le répertoire RDBMS\ADMIN et recherche le script UTLXPLAN.SQL

Ce script est très court et se contente de créer une table qui s'appelle PLAN_TABLE.

Créer cette table sous ton compte. Et si tu veux tracer ton premier plan d'exécution, tu fais sous SQL*Plus un SET AUTOTRACE TRACEONLY et tu balances une requête, genre un select tout bête histoire de voir.

Comme tu peux le voir, cet outil est très simple à utiliser. Par contre, il va te falloir un certiain temps pour être capable d'analyser ce plan d'exécution. Tu entendras parler de terme comme Full Scan de table, ou bien de Index Unique Scan, ou Index Range Scan.

Tu verras aussi les méthodes de jointure.

Au niveau doc, il y a la doc Oracle qui s'appelle 'Database Performance Tuning Guide and Reference'.Regarde le chapitre 9 'Using Explain Plan'.

Sinon, il y a les livres, très souvent en anglais. Ils s'appelent genre 'Tuning SQL' ou 'Optimisation des requêtes SQL'.

Pour finir, comme info, il existe aussi le tuning d'instance. Ca n'a rien à voir avec le tuning SQL.

[Shai_Hulud]

Merci bien mssiou