c'est l'histoire d'un gars qui bosse dans une fac. il se pointe au boulot un mardi matin, et on lui demande de bosser sur les bugs d'un programme à la compta.

alors je file en compta, le programme interroge mal une base de données: en gros un regroupement se fait mal.

je rentre au bureau, j'analyse les échanges entre le programme et la DB, trouve la procédure stockée incriminée. bon.

je procède au regroupement, ça roule! mais l'exécution prends tout de même 8 ( oui, huit ) minutes pour sortir les résultats.

Comment optimiser?

j'ai sorti le SELECT de la procédure et testé dans le SQL

8 minutes plus tard, j'élague une série de "case", qui sont peut être la source de la lenteur.

8 minutes plus tard ( c'était pas ça ), je vire un SELECT imbriqué.

3 secondes plus tard, je me rends compte que c'était ça.

Bon! mais alors, pourquoi est-ce que c'était lent?

je compte les lignes des tables:
_ tables principale: 750.000
_ table du SELECT imbriqué: 50.000
_ le reste des tables, c'est de la codification, des faibles volumes

ce SELECT mange des ressources, dû aux volumes des tables... alors comment y remédier?

je crée une table temporaire, en y insérant les données de base et un champ vide;
ensuite, je mets à jour un champ de cette table de quelques centaines de lignes avec la valeur de la table de 50.000.

10 secondes plus tard, ma solution est validée
pause café!

en résumer, pour résoudre une lenteur:
_ identifier la requete qui est lente
_ trouver pourquoi elle est lente ( volumes des tables? jointures? traitement des données? ... )
_ aboutir au résultat voulu par un moyen contournant le point noir
_ prendre un café

( _dire qu'on paie une SSII une fortune pour ce programme! ... ils pourraient au moins optimiser leur SQL!_ )

Bonne optimisation!

A+

Pascal

Petite question, ta requete imbriqué tu pouvais pas la remplacer par une jointure ?

Je bosse avec des bases de données depuis 8 et j'en ai fait de bien compliqué et j'ai hyper rarement eux besoin de faire des requêtes imbriqués !!! prob de conception de la base ?

j'ai essayé la jointure, c'était pire que tout, j'ai tué le processus au bout de 11 minutes...

la requete initiale était du style: ( je trouve ça louche, mais bon ... )

j'ai remplacé la partie avec table2 par un update sur table temporaire dans la suite du code.


je ne sais pas s'il y a un pb de conception, par contre la question du volume et de l'archivage de données se pose de plus en plus fort chaque année.

A+

Pascal

je ne sais pas s'il y a un pb de conception, par contre la question du volume et de l'archivage de données se pose de plus en plus fort chaque année.

Si y un prob du au volume c'est qu'il y a eu une mauvaise conception et étude au départ ! quand on sait que la base de données sera volumineuse on la concoit de facon à supporter le volume !

le soucis de la base de données, c'est que c'est une base pour gérer 4500 étudiants par an.

en clair, chaque année elle se prend pas mal de volume dans la tronche...
le module permettant de gérer l'archivage ( anciens étudiants ) n'est pas encore au point, so...

A+

Pascal

Un truc qui peut être pratique en phase de débuggage sous MySQL : activer le log des requêtes lentes :

ça sous passe sous Sybase.

A+

Pascal

Et Sybase ne possède pas de possibilités de journalisations aussi détaillée ? Si c'est le cas, c'est effectivement moins pratique