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 !
"Firetox" a écrit dans le message de news: 52309629$0$2405$
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
49810 tuples pour documlg 87 pour CUMUL
la clé choisie pour CUMUL est bien la clé compo (IDARTICLE+ETAT)
Pour les 49810 c'est normal car je parcours toutes ces lignes pour le cumul. Mais je ne sais pas à quoi correspond le 87 !
"Firetox" <fitretox@free.fr> a écrit dans le message de news:
52309629$0$2405$426a74cc@news.free.fr...
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
49810 tuples pour documlg
87 pour CUMUL
la clé choisie pour CUMUL est bien la clé compo (IDARTICLE+ETAT)
Pour les 49810 c'est normal car je parcours toutes ces lignes pour le cumul.
Mais je ne sais pas à quoi correspond le 87 !
"Firetox" a écrit dans le message de news: 52309629$0$2405$
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
49810 tuples pour documlg 87 pour CUMUL
la clé choisie pour CUMUL est bien la clé compo (IDARTICLE+ETAT)
Pour les 49810 c'est normal car je parcours toutes ces lignes pour le cumul. Mais je ne sais pas à quoi correspond le 87 !
I.G.LOG
Bonjour Firetox, J'ai finalement créé une clé composée sur IDDOCUM + IDARTICLE + ETAT et le temps de traitement de la requête est tombé à ... 1 seconde 80 (au lieu de 500 secondes) !!! Incroyable. En effet, le explain donne 1 au lieu de 87 sur CUMUL. Bref, je voulais éviter les clés composées, mais là c'est indispensable ! Encore merci pour ton aide toujours précieuse Phil
"Firetox" a écrit dans le message de news: 52309629$0$2405$
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" a écrit dans le message de news: 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
Bonjour Firetox,
J'ai finalement créé une clé composée sur IDDOCUM + IDARTICLE + ETAT
et le temps de traitement de la requête est tombé à ... 1 seconde 80 (au
lieu de 500 secondes) !!!
Incroyable.
En effet, le explain donne 1 au lieu de 87 sur CUMUL.
Bref, je voulais éviter les clés composées, mais là c'est indispensable !
Encore merci pour ton aide toujours précieuse
Phil
"Firetox" <fitretox@free.fr> a écrit dans le message de news:
52309629$0$2405$426a74cc@news.free.fr...
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$426a74cc@news.free.fr...
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" <fitretox@free.fr> a écrit dans le message de news:
52307eb6$0$2133$426a74cc@news.free.fr...
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$426a74cc@news.free.fr...
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
Bonjour Firetox, J'ai finalement créé une clé composée sur IDDOCUM + IDARTICLE + ETAT et le temps de traitement de la requête est tombé à ... 1 seconde 80 (au lieu de 500 secondes) !!! Incroyable. En effet, le explain donne 1 au lieu de 87 sur CUMUL. Bref, je voulais éviter les clés composées, mais là c'est indispensable ! Encore merci pour ton aide toujours précieuse Phil
"Firetox" a écrit dans le message de news: 52309629$0$2405$
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" a écrit dans le message de news: 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
oui je n'avais pas fait attention mais il y a un where sur iddocum et donc comme c'est un index il va parcourir par celui ou un autre et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas l'analyse dans le projet les index sont a créer ou a ajouter directement sur la base sans modification du prog
content d'avoir pu t'aider
@+
Bonjour,
oui je n'avais pas fait attention mais il y a un where sur iddocum et donc
comme c'est un index il va parcourir par celui ou un autre
et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index
c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas l'analyse
dans le projet les index sont a créer ou a ajouter directement sur la base
sans modification du prog
oui je n'avais pas fait attention mais il y a un where sur iddocum et donc comme c'est un index il va parcourir par celui ou un autre et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas l'analyse dans le projet les index sont a créer ou a ajouter directement sur la base sans modification du prog
content d'avoir pu t'aider
@+
Daniel
Bonjour,
Le 12/09/2013 10:31, Firetox a écrit :
Bonjour,
oui je n'avais pas fait attention mais il y a un where sur iddocum et donc comme c'est un index il va parcourir par celui ou un autre et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas l'analyse dans le projet les index sont a créer ou a ajouter directement sur la base sans modification du prog
content d'avoir pu t'aider
@+
depuis le temps que certains disent qu'un "Explain" est indispensable pour savoir ce que fait le moteur ;-)...
Pour info sur mysql un index (composé) se lit de gauche à droite, et par exemple si il y a l'index id-etat rien ne sert de faire un index sur id.
Pour le reste, oui il est absurde de coupler aussi étroitement programme et structure de donnée comme le fait l'analyse de l'ide. -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bonjour,
Le 12/09/2013 10:31, Firetox a écrit :
Bonjour,
oui je n'avais pas fait attention mais il y a un where sur iddocum et
donc comme c'est un index il va parcourir par celui ou un autre
et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index
c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas
l'analyse dans le projet les index sont a créer ou a ajouter
directement sur la base sans modification du prog
content d'avoir pu t'aider
@+
depuis le temps que certains disent qu'un "Explain" est indispensable
pour savoir ce que fait le moteur ;-)...
Pour info sur mysql un index (composé) se lit de gauche à droite, et par
exemple si il y a l'index
id-etat rien ne sert de faire un index sur id.
Pour le reste, oui il est absurde de coupler aussi étroitement programme
et structure de donnée comme le fait l'analyse de l'ide.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
oui je n'avais pas fait attention mais il y a un where sur iddocum et donc comme c'est un index il va parcourir par celui ou un autre et la cle qu'il fallait créée est bien celle que tu as trouvé (bravo)
parfois pour éviter les requetes lentes il faut ajouter des index c'est pour cela que travaillant avec sqlmanagerX et n'ayant pas l'analyse dans le projet les index sont a créer ou a ajouter directement sur la base sans modification du prog
content d'avoir pu t'aider
@+
depuis le temps que certains disent qu'un "Explain" est indispensable pour savoir ce que fait le moteur ;-)...
Pour info sur mysql un index (composé) se lit de gauche à droite, et par exemple si il y a l'index id-etat rien ne sert de faire un index sur id.
Pour le reste, oui il est absurde de coupler aussi étroitement programme et structure de donnée comme le fait l'analyse de l'ide. -- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
