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
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$426a74cc@news.free.fr...
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
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
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" a écrit dans le message de news:
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
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" <fitretox@free.fr> a écrit dans le message de news:
52304de7$0$2058$426a74cc@news.free.fr...
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$426a74cc@news.free.fr...
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
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" a écrit dans le message de news:
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
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
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$426a74cc@news.free.fr...
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
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
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
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
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
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
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
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
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)
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
WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
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)
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
WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
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
WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
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
WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
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)
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
WDIDX120618877624 : IDDOCUM (table documlg)
WDIDX120618877518 : IDARTICLE (table CUMUL - documlg)
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)