[WD12] Requete SQL sur base MySQL 5.1

Le
I.G.LOG
Bonjour à tous.

Je suis en train de mettre en place une consolidation des stocks, cad
enregistrer dans la base les qtés totales et pmps par article.
J'ai une table DOCUM dans laquelle sont mémorisés les différents stocks,
identifiés par la clé IDDOCUM.
Dans la table DOCUMLG, les lignes d'articles avec qté et prix (pmp).
Dans la même table DOCUM j'ai un tuple représentant le stock cumulé et dans
DOCUMLG tous les cumuls par article (avec le champ ETAT pour neuf ou
occasion).
J'essaie de construire un requête pour tester ces cumuls stocks.
La voici:

select documlg.IDARTICLE,documlg.ETAT,sum(documlg.QTEREST) as TOTQTE,
round(sum(documlg.QTEREST * documlg.PRIX) / sum(documlg.QTEREST),6) as PMP
,CUMUL.IDDOCUMLG,CUMUL.QTEREST as QTECUM, CUMUL.PRIX as PMPCUM
from documlg
left join documlg as CUMUL
on CUMUL.IDARTICLE = documlg.IDARTICLE
and CUMUL.IDDOCUM = 212012
// Le stock cumuls
and CUMUL.ETAT = documlg.ETAT
where documlg.IDDOCUM in
(129006,128559,128731,1,128567,8,3,6,137521,5,182626) // Les
différents stocks
group by documlg.IDARTICLE,documlg.ETAT
having (TOTQTE <> QTECUM) or (PMP <> PMPCUM)

Cette requête cumule chaque article (même ceux à qté zéro, pour tester le
cas où le cumul est positif), calcule le PMP total et compare les résultats
avec ceux des cumuls.
J'ai exécuté une première fois cette requête qui m'a donnée un résultat en
255 secondes, mais qui, bizarrement, me donnait des tuples avec qtés et pmp
égaux ?!?
Mais depuis un moment, cette même requête semble mouliner à l'infini, et je
dois rebooter le pc !
Bref, je ne m'en sors pas !

Merci pour votre aide
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
I.G.LOG
Le #25651272
Bon, il semblerait que la base était corrompu ; en restaurant, tout est
rentré dans l'ordre !
En revanche 4 minutes c'est long. Voyez-vous un moyen d'optimiser cette
requête ?
Encore merci
Firetox
Le #25651532
Bonjour,

execute ta requete avec EXPLAIN devant le SELECT
et montre nous le resultat : cela indiquera les elements qui pechent et les
index manquant



"I.G.LOG" a écrit dans le message de groupe de discussion :
52302aed$0$3729$

Bon, il semblerait que la base était corrompu ; en restaurant, tout est
rentré dans l'ordre !
En revanche 4 minutes c'est long. Voyez-vous un moyen d'optimiser cette
requête ?
Encore merci
I.G.LOG
Le #25651832
Bonjour Firetox,
Voici l'explain, que j'avais déjà exécuté mais sans pouvoir l'interpréter
correctement (je ne connais pas bien cette commande)

#
# Requête:
# explain select
documlg.IDARTICLE,documlg.ETAT,documlg.DESIGNATION,documlg.REFCONST ,
# sum(documlg.QTEREST) as TOTQTE, round(sum(documlg.QTEREST * documlg.PRIX)
/ sum(documlg.QTEREST),5) as PMP ,
# CUMUL.IDDOCUMLG,CUMUL.QTEREST as QTECUM, round(CUMUL.PRIX,5) as PMPCUM
# from documlg
# left join documlg as CUMUL
# on CUMUL.IDARTICLE = documlg.IDARTICLE
# and CUMUL.IDDOCUM = 212313
# and CUMUL.ETAT = documlg.ETAT
# where documlg.IDDOCUM in
(129006,128559,128731,1,128567,8,3,6,137521,5,182626,169947,169300,2,170020,108021,4,7)
# group by documlg.IDARTICLE,documlg.ETAT
# having (TOTQTE <> QTECUM) or (PMP <> PMPCUM)
#
'id','select_type','table' ,'type' ,'possible_keys'
,'key','key_len','ref','rows','Extra'
'1','SIMPLE','documlg','range','WDIDX120618877624','WDIDX120618877624','9','[NULL]','49198','Using
where; Using temporary; Using filesort'
'1','SIMPLE','CUMUL','ref' ,'WDIDX120618877624,WDIDX120618877518
,WDIDX120618877523','WDIDX120618877518','9','techavia.documlg.IDARTICLE','128',''

Dans la table documlg (et donc CUMUL) tout les champs de la requête sont des
index, sauf QTEREST et PRIX (objet du sum) !
Merci

"Firetox" 52304de7$0$2058$
Bonjour,

execute ta requete avec EXPLAIN devant le SELECT
et montre nous le resultat : cela indiquera les elements qui pechent et
les index manquant



"I.G.LOG" a écrit dans le message de groupe de discussion :
52302aed$0$3729$

Bon, il semblerait que la base était corrompu ; en restaurant, tout est
rentré dans l'ordre !
En revanche 4 minutes c'est long. Voyez-vous un moyen d'optimiser cette
requête ?
Encore merci

I.G.LOG
Le #25651852
pour info, les index choisis par MySQL :

WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)

choix qui semble convenable !

"I.G.LOG" 52307620$0$3456$
Bonjour Firetox,
Voici l'explain, que j'avais déjà exécuté mais sans pouvoir l'interpréter
correctement (je ne connais pas bien cette commande)

#
# Requête:
# explain select
documlg.IDARTICLE,documlg.ETAT,documlg.DESIGNATION,documlg.REFCONST ,
# sum(documlg.QTEREST) as TOTQTE, round(sum(documlg.QTEREST *
documlg.PRIX) / sum(documlg.QTEREST),5) as PMP ,
# CUMUL.IDDOCUMLG,CUMUL.QTEREST as QTECUM, round(CUMUL.PRIX,5) as PMPCUM
# from documlg
# left join documlg as CUMUL
# on CUMUL.IDARTICLE = documlg.IDARTICLE
# and CUMUL.IDDOCUM = 212313
# and CUMUL.ETAT = documlg.ETAT
# where documlg.IDDOCUM in
(129006,128559,128731,1,128567,8,3,6,137521,5,182626,169947,169300,2,170020,108021,4,7)
# group by documlg.IDARTICLE,documlg.ETAT
# having (TOTQTE <> QTECUM) or (PMP <> PMPCUM)
#
'id','select_type','table' ,'type' ,'possible_keys'
,'key','key_len','ref','rows','Extra'
'1','SIMPLE','documlg','range','WDIDX120618877624','WDIDX120618877624','9','[NULL]','49198','Using
where; Using temporary; Using filesort'
'1','SIMPLE','CUMUL','ref' ,'WDIDX120618877624,WDIDX120618877518
,WDIDX120618877523','WDIDX120618877518','9','techavia.documlg.IDARTICLE','128',''

Dans la table documlg (et donc CUMUL) tout les champs de la requête sont
des index, sauf QTEREST et PRIX (objet du sum) !
Merci

"Firetox" 52304de7$0$2058$
Bonjour,

execute ta requete avec EXPLAIN devant le SELECT
et montre nous le resultat : cela indiquera les elements qui pechent et
les index manquant



"I.G.LOG" a écrit dans le message de groupe de discussion :
52302aed$0$3729$

Bon, il semblerait que la base était corrompu ; en restaurant, tout est
rentré dans l'ordre !
En revanche 4 minutes c'est long. Voyez-vous un moyen d'optimiser cette
requête ?
Encore merci





Firetox
Le #25651892
Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'

du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file sort
soit en creant des index soit en changeant le order de la requete au cas ou
(il est plus efficace de faire un select imbriqué en enlevant le order pour
le fair eplus tard

bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire pour
voir la diff dans explain
sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes





"I.G.LOG" a écrit dans le message de groupe de discussion :
52307620$0$3456$

Bonjour Firetox,
Voici l'explain, que j'avais déjà exécuté mais sans pouvoir l'interpréter
correctement (je ne connais pas bien cette commande)

#
# Requête:
# explain select
documlg.IDARTICLE,documlg.ETAT,documlg.DESIGNATION,documlg.REFCONST ,
# sum(documlg.QTEREST) as TOTQTE, round(sum(documlg.QTEREST * documlg.PRIX)
/ sum(documlg.QTEREST),5) as PMP ,
# CUMUL.IDDOCUMLG,CUMUL.QTEREST as QTECUM, round(CUMUL.PRIX,5) as PMPCUM
# from documlg
# left join documlg as CUMUL
# on CUMUL.IDARTICLE = documlg.IDARTICLE
# and CUMUL.IDDOCUM = 212313
# and CUMUL.ETAT = documlg.ETAT
# where documlg.IDDOCUM in
(129006,128559,128731,1,128567,8,3,6,137521,5,182626,169947,169300,2,170020,108021,4,7)
# group by documlg.IDARTICLE,documlg.ETAT
# having (TOTQTE <> QTECUM) or (PMP <> PMPCUM)
#
'id','select_type','table' ,'type' ,'possible_keys'
,'key','key_len','ref','rows','Extra'
'1','SIMPLE','documlg','range','WDIDX120618877624','WDIDX120618877624','9','[NULL]','49198','Using
where; Using temporary; Using filesort'
'1','SIMPLE','CUMUL','ref' ,'WDIDX120618877624,WDIDX120618877518
,WDIDX120618877523','WDIDX120618877518','9','techavia.documlg.IDARTICLE','128',''

Dans la table documlg (et donc CUMUL) tout les champs de la requête sont des
index, sauf QTEREST et PRIX (objet du sum) !
Merci

"Firetox" 52304de7$0$2058$
Bonjour,

execute ta requete avec EXPLAIN devant le SELECT
et montre nous le resultat : cela indiquera les elements qui pechent et
les index manquant



"I.G.LOG" a écrit dans le message de groupe de discussion :
52302aed$0$3729$

Bon, il semblerait que la base était corrompu ; en restaurant, tout est
rentré dans l'ordre !
En revanche 4 minutes c'est long. Voyez-vous un moyen d'optimiser cette
requête ?
Encore merci

I.G.LOG
Le #25651882
Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'



C'est bien ce que je pensais, mais comment l'éviter puisque tous les champs
sont indexés !?


du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file
sort soit en creant des index soit en changeant le order de la requete au
cas ou (il est plus efficace de faire un select imbriqué en enlevant le
order pour le fair eplus tard



il n'y a pas de order, uniquement un group by !?


bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire pour
voir la diff dans explain



les deux champs sont bien indexés ! tous en fait, sauf les champs du sum() !

sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes




WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
Firetox
Le #25651872
nono justement il te faut un index sur les deux et pas un index sur chaque
donc cree un index sur IDarticle, etat
et relance le explain et tu verras des diff

le order ou le group by determine la cle selectionné ou l'index poir le
parcours ce qui fera le temps
et les file sort ou temporary

il faut eterminer ce qui provoque le temporary et le file sort pour avoir un
index l'evitant


"I.G.LOG" a écrit dans le message de groupe de discussion :
52307d7e$0$2046$


Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'



C'est bien ce que je pensais, mais comment l'éviter puisque tous les champs
sont indexés !?


du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file
sort soit en creant des index soit en changeant le order de la requete au
cas ou (il est plus efficace de faire un select imbriqué en enlevant le
order pour le fair eplus tard



il n'y a pas de order, uniquement un group by !?


bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire pour
voir la diff dans explain



les deux champs sont bien indexés ! tous en fait, sauf les champs du sum() !

sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes




WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
I.G.LOG
Le #25651952
J'ai créé une clé composée sur IDARTICLE+ETAT
Elle est bien choisie pas MySQL dans le explain.
Par contre, pas de changement au niveau des temps de réponse (peut-être 2 ou
3% plus rapide)

"Firetox" 52307eb6$0$2133$
nono justement il te faut un index sur les deux et pas un index sur chaque
donc cree un index sur IDarticle, etat
et relance le explain et tu verras des diff

le order ou le group by determine la cle selectionné ou l'index poir le
parcours ce qui fera le temps
et les file sort ou temporary

il faut eterminer ce qui provoque le temporary et le file sort pour avoir
un index l'evitant


"I.G.LOG" a écrit dans le message de groupe de discussion :
52307d7e$0$2046$


Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'



C'est bien ce que je pensais, mais comment l'éviter puisque tous les
champs
sont indexés !?


du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file
sort soit en creant des index soit en changeant le order de la requete au
cas ou (il est plus efficace de faire un select imbriqué en enlevant le
order pour le fair eplus tard



il n'y a pas de order, uniquement un group by !?


bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire
pour voir la diff dans explain



les deux champs sont bien indexés ! tous en fait, sauf les champs du sum()
!

sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes




WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)


I.G.LOG
Le #25651992
... et toujours filesort et tempory

"I.G.LOG" 5230867e$0$3442$
J'ai créé une clé composée sur IDARTICLE+ETAT
Elle est bien choisie pas MySQL dans le explain.
Par contre, pas de changement au niveau des temps de réponse (peut-être 2
ou 3% plus rapide)

"Firetox" 52307eb6$0$2133$
nono justement il te faut un index sur les deux et pas un index sur
chaque
donc cree un index sur IDarticle, etat
et relance le explain et tu verras des diff

le order ou le group by determine la cle selectionné ou l'index poir le
parcours ce qui fera le temps
et les file sort ou temporary

il faut eterminer ce qui provoque le temporary et le file sort pour avoir
un index l'evitant


"I.G.LOG" a écrit dans le message de groupe de discussion :
52307d7e$0$2046$


Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'



C'est bien ce que je pensais, mais comment l'éviter puisque tous les
champs
sont indexés !?


du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file
sort soit en creant des index soit en changeant le order de la requete
au cas ou (il est plus efficace de faire un select imbriqué en enlevant
le order pour le fair eplus tard



il n'y a pas de order, uniquement un group by !?


bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire
pour voir la diff dans explain



les deux champs sont bien indexés ! tous en fait, sauf les champs du
sum() !

sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes




WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)






Firetox
Le #25652102
que dis l'explain sue la requetes ?
car maintenant il va falloir voir le nombre de ligne traité pour arriver au
resultat et les tuples necessaires
et qui suivant les cas devront etre reduit



"I.G.LOG" a écrit dans le message de groupe de discussion :
5230867e$0$3442$

J'ai créé une clé composée sur IDARTICLE+ETAT
Elle est bien choisie pas MySQL dans le explain.
Par contre, pas de changement au niveau des temps de réponse (peut-être 2 ou
3% plus rapide)

"Firetox" 52307eb6$0$2133$
nono justement il te faut un index sur les deux et pas un index sur chaque
donc cree un index sur IDarticle, etat
et relance le explain et tu verras des diff

le order ou le group by determine la cle selectionné ou l'index poir le
parcours ce qui fera le temps
et les file sort ou temporary

il faut eterminer ce qui provoque le temporary et le file sort pour avoir
un index l'evitant


"I.G.LOG" a écrit dans le message de groupe de discussion :
52307d7e$0$2046$


Ton probleme de lenteur vient de la :
'Using where; Using temporary; Using filesort'



C'est bien ce que je pensais, mais comment l'éviter puisque tous les
champs
sont indexés !?


du fait du temporay et du fileSort plus il y a aura de ligne et plus ta
requete sera lente il faut dans l'Explain ecviter les temporary et file
sort soit en creant des index soit en changeant le order de la requete au
cas ou (il est plus efficace de faire un select imbriqué en enlevant le
order pour le fair eplus tard



il n'y a pas de order, uniquement un group by !?


bref on va y aller par etapes
deja : il va utiliser la cle : WDIDX120618877624

or il faudrait qu'il utilise une cle sur documlg.IDARTICLE,documlg.ETAT
donc si tu n'as pas d'index sur IDArticle, etat il fautdrait en faire
pour voir la diff dans explain



les deux champs sont bien indexés ! tous en fait, sauf les champs du sum()
!

sur mysql tu peux faire l'index directement dans la base sans modif sur
windev juste sur les data

ensuite on verra
sinon que contient l'index WDIDX120618877624 comme colonnes




WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)


Publicité
Poster une réponse
Anonyme