Discussion :

[lbar012001]

Bonjour,
je souhaiterai savoir s'il existe quelque part un document ou bien des avis d'experts qui pourraient me dire ce qui dans un code SQL est susceptible d'être gourmand ou pas.
J'utilise PL/SQL sur des très gros tables (+100 000 000 enr) mais n'ai pas accès ni la trace ni à la structure des tables (index...) donc je manipule un peu en aveugle.
Et donc parfois ça rame fort.

Quelques exemples
Des fonctions de type SUBSTR ou TO_CHAR, ou des concaténations, soit dans le SELECT ou le WHERE ou des IN ou <> dans le WHERE...
bref est ce qu'il y a des fonctions à proscrire car potentiellement trop gourmandes ?

ou bien si c'est simplement la volumes de données et les jointures utilisées qui font que ça rame

merci de vos avis
Laurent

[Kloun]

Bonjour,

Tu travailles comment ?
Tables Access ? Tables sur un autre SGBD ? Lequel ?
Tables liées ? SQL direct ? Autre ?

[Richard_35]

Bonjour lbar012001,

La question primordiale est de savoir si PL/SQL est capable de définir, de lui-même, l'index à utiliser, même si la requête utilise la table "physique". Autrement dit, si PL/SQL optimise le chemin d'accès aux données (index) à partir de la table "physique".

• si oui, c'est un premier point positif ;
• si non, donc si PL/SQL n'analyse que la(es) table(s) indiquée(s) dans la clause FROM sans s'occuper des index, alors tu devras connaître le nom des index et les champs composant cet index pour optimiser la requête.

En tout état de cause, une liste (non exhaustive) des comportements gourmands en ressource :

• une jointure est plus gourmande qu'une table unique : évident... ;
• la clause GROUP BY : elle regroupe des records, pas forcément dans l'ordre "physique", par un ensemble de champs défini ;
• dans la clause WHERE, les LIKE "*xyz" et LIKE "*xyz*" sont très gourmands car SQL "se balade" à l'intérieur du champ concerné (tous les caractères) pour tous les records. Contrairement à LIKE "xyz*" qui se contente de sélectionner "commence par".

D'une manière générale, il suffit de se mettre à la place de la machine pour "sentir" le travail à effectuer.

[lbar012001]

merci,

en fait je me suis rendu compte d'un truc qui change tout

j'ai 2 champs A et B contenant chacun des codes de 2 caractères

Si dans le where je mets du

Code :

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

B <> 'XX'

ça va vite

Si je mets du

Code :

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

A <> 'YY'

ça marche vite aussi

Par contre si je concatène, et j'ai souvent besoin de faire ça, en faisant du

Code :

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

A||B <> 'XXYY'

là ça rame complètement.

[Richard_35]

Si tu te mets à la place de la machine, le job à effectuer à chaque enregistrement, pour tes 100.000.000 records, ce n'est pas réellement étonnant.

Tu es dans un forum Access... peut-être existe-t-il un forum PL/SQL.

Néanmoins, si PL/SQL ressemble à SQL Server, une "vue" avec ces deux champs concaténés pourrait réduire, significativement, ton temps de traitement.

[lbar012001]

En fait c'est la concaténation dans le WHERE qui fait tout ramer, dans le SELECT ou dans le GROUP BY, pas de souci.
Merci en tout cas.
Laurent