Discussion :

[tulipe_rose]

Bonjours à vous tous,
J'ai une requête énorme qui doit être décomposée et optimisée, elle est de la forme:

Code :

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

1
2
3
4
5
6
7
8
SELECT Table.champ, REQ_1.CHAMPS_1, REQ_1.CHAMPS_2,... REQ_1.CHAMPS_X  , REQ_2.CHAMPS_1,...  REQ_N.CHAMPS_Y
FROM 
        Left Join REQ_1 ON (COND_1)
        LEFT JOIN REQ_2 ON (COND_2)
        ...
        Left JOIN REQ_N.CHAMPS_M  (COND_N)
 
WHERE Table.champ=.. ;

Merci d'avance pour votre aide

[Waldar]

Qu'est-ce qui ne va pas avec la requête actuelle ?

Par contre sans le code complet ni le SGBD, il n'y a pas grand-chose que nous puissions faire ici.

[tulipe_rose]

D'abord merci pour votre réponse,
La requête actuelle est énorme, elle est très longue, et ils m'ont demandée de la décomposer et l'optimiser au maximum pour des raisons de lisibilité et maintenabilité.. le SGBD est MySQL.. et la forme générale de la requête est celle que j'ai écrit précédemment.. Je ne sais pas quoi faire ou par ou commencer!

[StringBuilder]

Bonjour,

Votre requête me semble, au vu du peu d'information qu'on a, tout à fait "propre" en termes SQL.
En effet, que des jointures simples, pas de case et autres fonctions coûteuses et indéchiffrables dans le select ni dans le where.

En revanche, vos tables "REQ_1" ... "REQ_N" ne me plaisent pas trop.

Ont elles la même structure ?

Si oui, alors le suffixe me semble on ne peut plus foireux, et signe d'une erreur magistrale de conception/modélisation.

Une unique table "REQ" devrait éxister, avec une colonne supplémentaire "N", correspondant aux valeurs de vos suffixes.

Sinon, qui est ce "on" qui vous demande de simplifier votre code SQL ? Le concepteur du modèle des données ? Le même que celui qui a choisi MySQL comme SGBD-R ?

[escartefigue]

Que des requetes outer, avec a priori un grand nombre de tables jointes et a priori aussi, toutes les colonnes de chacune des tables de la requete

Si les tables ont des millions de lignes et/ou il y a beaucoup de tables jointes en outer et/ou les colonnes sont larges, il faut transporter beaucoup de données, le temps de traitement s'en ressent forcément, même avec des chemins d'accès optimisés.

Vérifiez si toutes les colonnes transportées sont vraiment utiles, à commencer par les plus larges

Ceci étant, sans savoir si le where est filtrant, sans le DDL des tables et index et sans les stats, difficile d'argumenter de façon plus détaillée