Bonjour,
J'utilise WD8 315j et MySQL 4.0.20c.
L'affichage des tables fichier est extremement lent sur MySQL
-notamment sur les tables importantes- alors qu'avec HF c'est
instantané. A titre d'exemple, sur une table de 5000 enregistrement,
comportant des liens sur d'autre fichiers dans le code "affichage
d'une ligne", l'affichage de la 1ere page met 20 secondes avec MySQL
contre 0,5 secondes avec HF (pour le meme code). ensuite, le parcours
de la table est beaucoup moins "veloce" avec MySQL (avec PgDn, temps
d'attente de qq secondes toutes les 3 pages alors qu'il n'y a pas ce
ralentissement avec HF).
Connaissez vous un moyen de regler ce probleme (je suis en local et
j'ai peur des resultats en exploitation reseau !)
Bonjour,
J'utilise WD8 315j et MySQL 4.0.20c.
L'affichage des tables fichier est extremement lent sur MySQL
-notamment sur les tables importantes- alors qu'avec HF c'est
instantané. A titre d'exemple, sur une table de 5000 enregistrement,
comportant des liens sur d'autre fichiers dans le code "affichage
d'une ligne", l'affichage de la 1ere page met 20 secondes avec MySQL
contre 0,5 secondes avec HF (pour le meme code). ensuite, le parcours
de la table est beaucoup moins "veloce" avec MySQL (avec PgDn, temps
d'attente de qq secondes toutes les 3 pages alors qu'il n'y a pas ce
ralentissement avec HF).
Connaissez vous un moyen de regler ce probleme (je suis en local et
j'ai peur des resultats en exploitation reseau !)
Bonjour,
J'utilise WD8 315j et MySQL 4.0.20c.
L'affichage des tables fichier est extremement lent sur MySQL
-notamment sur les tables importantes- alors qu'avec HF c'est
instantané. A titre d'exemple, sur une table de 5000 enregistrement,
comportant des liens sur d'autre fichiers dans le code "affichage
d'une ligne", l'affichage de la 1ere page met 20 secondes avec MySQL
contre 0,5 secondes avec HF (pour le meme code). ensuite, le parcours
de la table est beaucoup moins "veloce" avec MySQL (avec PgDn, temps
d'attente de qq secondes toutes les 3 pages alors qu'il n'y a pas ce
ralentissement avec HF).
Connaissez vous un moyen de regler ce probleme (je suis en local et
j'ai peur des resultats en exploitation reseau !)
Première question : tu utilises quel accès pour accéder à MySQL ?
L'utilisation des select ... Limit ...
Première question : tu utilises quel accès pour accéder à MySQL ?
L'utilisation des select ... Limit ...
Première question : tu utilises quel accès pour accéder à MySQL ?
L'utilisation des select ... Limit ...
Bonjour,Première question : tu utilises quel accès pour accéder à MySQL ?
Dans ce cas, j'utilise l'acces natif PcSoft (le dernier mis en
telechargement)
L'utilisation des select ... Limit ...
J'ai fait cet essai avec "select... limit" mais ce n'est applicable
que sur les tables de taille "raisonnables": sur les tables
importantes, les performances s'ecroulent sur les derniers
enregistrements car le limit est recalcule a chaque fois (apres un
quinzaine de PgDn, il faut plusieurs secondes pour que les pages
soient affichees). De plus, j'ai besoin de pouvoir trier la table en
fonction de plusieurs criteres. un exemple: table des articles,
l'utilisateur peut effectuer des recherches/parcours par N°
d'article, Référence et Désignation (a noter d'ailleurs, l'affichage
est + rapide qd on tri par le n° d'article -numerique- et beaucoup
moins par ref et designation -alpha). Je me suis "cassé la tete" pour
developper un browser dynamique, base sur le select limit, permettant
les tris sur plusieurs cles, mais, sans le concept de n° physique
d'enregistrement, je ne pense pas qu'il y ait une solution (avec le
pointeur sur le fichier data, il suffit de changer d'index en
conservant ce pointeur et le tour est joué; je pense que HF
fonctionne comme ca. Mais en SQL, pas possible !?!)
Merci
Bonjour,
Première question : tu utilises quel accès pour accéder à MySQL ?
Dans ce cas, j'utilise l'acces natif PcSoft (le dernier mis en
telechargement)
L'utilisation des select ... Limit ...
J'ai fait cet essai avec "select... limit" mais ce n'est applicable
que sur les tables de taille "raisonnables": sur les tables
importantes, les performances s'ecroulent sur les derniers
enregistrements car le limit est recalcule a chaque fois (apres un
quinzaine de PgDn, il faut plusieurs secondes pour que les pages
soient affichees). De plus, j'ai besoin de pouvoir trier la table en
fonction de plusieurs criteres. un exemple: table des articles,
l'utilisateur peut effectuer des recherches/parcours par N°
d'article, Référence et Désignation (a noter d'ailleurs, l'affichage
est + rapide qd on tri par le n° d'article -numerique- et beaucoup
moins par ref et designation -alpha). Je me suis "cassé la tete" pour
developper un browser dynamique, base sur le select limit, permettant
les tris sur plusieurs cles, mais, sans le concept de n° physique
d'enregistrement, je ne pense pas qu'il y ait une solution (avec le
pointeur sur le fichier data, il suffit de changer d'index en
conservant ce pointeur et le tour est joué; je pense que HF
fonctionne comme ca. Mais en SQL, pas possible !?!)
Merci
Bonjour,Première question : tu utilises quel accès pour accéder à MySQL ?
Dans ce cas, j'utilise l'acces natif PcSoft (le dernier mis en
telechargement)
L'utilisation des select ... Limit ...
J'ai fait cet essai avec "select... limit" mais ce n'est applicable
que sur les tables de taille "raisonnables": sur les tables
importantes, les performances s'ecroulent sur les derniers
enregistrements car le limit est recalcule a chaque fois (apres un
quinzaine de PgDn, il faut plusieurs secondes pour que les pages
soient affichees). De plus, j'ai besoin de pouvoir trier la table en
fonction de plusieurs criteres. un exemple: table des articles,
l'utilisateur peut effectuer des recherches/parcours par N°
d'article, Référence et Désignation (a noter d'ailleurs, l'affichage
est + rapide qd on tri par le n° d'article -numerique- et beaucoup
moins par ref et designation -alpha). Je me suis "cassé la tete" pour
developper un browser dynamique, base sur le select limit, permettant
les tris sur plusieurs cles, mais, sans le concept de n° physique
d'enregistrement, je ne pense pas qu'il y ait une solution (avec le
pointeur sur le fichier data, il suffit de changer d'index en
conservant ce pointeur et le tour est joué; je pense que HF
fonctionne comme ca. Mais en SQL, pas possible !?!)
Merci
> Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
après un optimize table ?
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
> Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
après un optimize table ?
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
> Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
après un optimize table ?
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Ce n'est pas normal, c'est qu'il te manque un index sur cette
colonne, que ta table est un peu comme du gruyère ou son index. Que
donnent les résultats après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des
cles !)
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
requete integralement, PUIS compter les 15000 premiers tuples pour
pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
de perf sur les derniers tuples) ?!
Ce n'est pas normal, c'est qu'il te manque un index sur cette
colonne, que ta table est un peu comme du gruyère ou son index. Que
donnent les résultats après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des
cles !)
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
requete integralement, PUIS compter les 15000 premiers tuples pour
pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
de perf sur les derniers tuples) ?!
Ce n'est pas normal, c'est qu'il te manque un index sur cette
colonne, que ta table est un peu comme du gruyère ou son index. Que
donnent les résultats après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des
cles !)
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
requete integralement, PUIS compter les 15000 premiers tuples pour
pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
de perf sur les derniers tuples) ?!
I.G.LOG a émis l'idée suivante :Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé
la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table
articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le
n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Pour en avoir le coeur net, je pense qu'il te faut capturer tes requêtes dans
le presse papier et les faire jouer depuis un frontal mySQL (SQLyog, mysqlcc
...)
S'il y a un LIMIT, il n'y a aucune raison que la reqûete ne retourne plus de
tuples ???
(en natif tout au moins).
Commence donc à isoler ton problème.
Cela vient de ma base mySQL ?
Cela vient de l'accès ?
Avant d'utiliser mySQL avec WinDev il est à mon avis indispensable de savoir
l'attaquer hors WinDev et je ne saurais que trop vous conseiller
l'utilisation d'un frontal C/S. MySQL en ligne de commande, c'est d'un autre
age et phpmyadmin c'est limité. Avec un produit comme SQLyog, tout est plus
simple ensuite. (n'est ce pas Jacques ?)
I.G.LOG a émis l'idée suivante :
Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)
Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé
la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table
articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le
n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Pour en avoir le coeur net, je pense qu'il te faut capturer tes requêtes dans
le presse papier et les faire jouer depuis un frontal mySQL (SQLyog, mysqlcc
...)
S'il y a un LIMIT, il n'y a aucune raison que la reqûete ne retourne plus de
tuples ???
(en natif tout au moins).
Commence donc à isoler ton problème.
Cela vient de ma base mySQL ?
Cela vient de l'accès ?
Avant d'utiliser mySQL avec WinDev il est à mon avis indispensable de savoir
l'attaquer hors WinDev et je ne saurais que trop vous conseiller
l'utilisation d'un frontal C/S. MySQL en ligne de commande, c'est d'un autre
age et phpmyadmin c'est limité. Avec un produit comme SQLyog, tout est plus
simple ensuite. (n'est ce pas Jacques ?)
I.G.LOG a émis l'idée suivante :Ce n'est pas normal, c'est qu'il te manque un index sur cette colonne, que
ta table est un peu comme du gruyère ou son index. Que donnent les
résultats
après un optimize table ?
Pas de changement majeur (toutes les colonnes de tris sont bien des cles !)Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
allouée aux tris MySQL est de combien ?
Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai utilisé
la
fonction HOptimise de WD8: pas d'ammelioration notable non plus).
Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une requete
qui retourne 80.000 tuples (c'est le cas dans mon exemple de table
articles)
le LIMIT 15001,12 (par ex) doit bien effectuer la requete integralement,
PUIS compter les 15000 premiers tuples pour pouvoir se positionner sur le
n°
15001 (se qui expliquerait la baisse de perf sur les derniers tuples) ?!
Pour en avoir le coeur net, je pense qu'il te faut capturer tes requêtes dans
le presse papier et les faire jouer depuis un frontal mySQL (SQLyog, mysqlcc
...)
S'il y a un LIMIT, il n'y a aucune raison que la reqûete ne retourne plus de
tuples ???
(en natif tout au moins).
Commence donc à isoler ton problème.
Cela vient de ma base mySQL ?
Cela vient de l'accès ?
Avant d'utiliser mySQL avec WinDev il est à mon avis indispensable de savoir
l'attaquer hors WinDev et je ne saurais que trop vous conseiller
l'utilisation d'un frontal C/S. MySQL en ligne de commande, c'est d'un autre
age et phpmyadmin c'est limité. Avec un produit comme SQLyog, tout est plus
simple ensuite. (n'est ce pas Jacques ?)
I.G.LOG wrote:
>> Ce n'est pas normal, c'est qu'il te manque un index sur cette
>> colonne, que ta table est un peu comme du gruyère ou son index. Que
>> donnent les résultats après un optimize table ?
>>
> Pas de changement majeur (toutes les colonnes de tris sont bien des
> cles !)
OK
>> Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
>> allouée aux tris MySQL est de combien ?
>>
> Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
> utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
> plus).
Tu lances la commande sous ton frontal préféré : optimize table ARTICLES;
si tu as la requete générée par Windev tu la récupères dans le presse
tu ajoutes EXPLAIN devant le select et tu nous renvoies le résultat de la
requete
Sinon des liens :
http://dev.mysql.com/doc/mysql/fr/Where_optimisations.html
http://www.nexen.net/docs/mysql/annotee/limit-optimisation.php
Concernant la taille allouée pour les tris c'est dans ton my.ini
> Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
> requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
> table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
> requete integralement, PUIS compter les 15000 premiers tuples pour
> pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
> de perf sur les derniers tuples) ?!
Normalement non...
I.G.LOG wrote:
>> Ce n'est pas normal, c'est qu'il te manque un index sur cette
>> colonne, que ta table est un peu comme du gruyère ou son index. Que
>> donnent les résultats après un optimize table ?
>>
> Pas de changement majeur (toutes les colonnes de tris sont bien des
> cles !)
OK
>> Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
>> allouée aux tris MySQL est de combien ?
>>
> Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
> utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
> plus).
Tu lances la commande sous ton frontal préféré : optimize table ARTICLES;
si tu as la requete générée par Windev tu la récupères dans le presse
tu ajoutes EXPLAIN devant le select et tu nous renvoies le résultat de la
requete
Sinon des liens :
http://dev.mysql.com/doc/mysql/fr/Where_optimisations.html
http://www.nexen.net/docs/mysql/annotee/limit-optimisation.php
Concernant la taille allouée pour les tris c'est dans ton my.ini
> Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
> requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
> table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
> requete integralement, PUIS compter les 15000 premiers tuples pour
> pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
> de perf sur les derniers tuples) ?!
Normalement non...
I.G.LOG wrote:
>> Ce n'est pas normal, c'est qu'il te manque un index sur cette
>> colonne, que ta table est un peu comme du gruyère ou son index. Que
>> donnent les résultats après un optimize table ?
>>
> Pas de changement majeur (toutes les colonnes de tris sont bien des
> cles !)
OK
>> Que donne l'explain plan de ta requete sous MySQL ? La taille mémoire
>> allouée aux tris MySQL est de combien ?
>>
> Euh... je n'en suis pas encore la sous MySQL :-( Par contre, j'ai
> utilisé la fonction HOptimise de WD8: pas d'ammelioration notable non
> plus).
Tu lances la commande sous ton frontal préféré : optimize table ARTICLES;
si tu as la requete générée par Windev tu la récupères dans le presse
tu ajoutes EXPLAIN devant le select et tu nous renvoies le résultat de la
requete
Sinon des liens :
http://dev.mysql.com/doc/mysql/fr/Where_optimisations.html
http://www.nexen.net/docs/mysql/annotee/limit-optimisation.php
Concernant la taille allouée pour les tris c'est dans ton my.ini
> Je pense vraiment que le LIMIT est recalcule a chaque fois; sur une
> requete qui retourne 80.000 tuples (c'est le cas dans mon exemple de
> table articles) le LIMIT 15001,12 (par ex) doit bien effectuer la
> requete integralement, PUIS compter les 15000 premiers tuples pour
> pouvoir se positionner sur le n° 15001 (se qui expliquerait la baisse
> de perf sur les derniers tuples) ?!
Normalement non...
Bonjour,
Suite à vos conseils, j'ai effectué la requete simple "select * from
articles where qte = 1 order by designation limit 15000,20" avec MySQL
Control Center 0.9.4-beta
Résultat : 20 rows en 0,11 sec. (vive MySQL !)
Ce test est effectué sur mon poste de dev en local, P4-2.6, RAM 1Go.
Jai fait mes premiers essais de LIMIT avec SQLManagerX (SQLTable)
avec cette requete, sans le where qte=1 (parcours de la table
articles, sans filtre, ordonné sur la clé designation) et j'avais
bien des ralentissements au fur et a mesure que j'avancais par PgDn
vers le bas de la table (instantané sur les premieres pages, mais
vers les enreg 60.000, il fallait environ 10 sec pour afficher la
page). Ces essais ont été fait sur portable PII-233, 196Mo de RAM, en
local. Et, dans ce cas, je ne passe pas par l'acces natif de PCSoft !
Donc, je ne comprends pas trop l'origine du probleme (vitesse proc,
mémoire, ... ????)
Pour revenir sur mes essais en cours: j'utilise l'acces natif de
PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
ligne" je fais des recherches sur 7 autres fichiers par
HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
RAM en local) et je pense que sur le reseau avec des clients moins
performants, ca ne va pas etre genial !
Merci encore pour tous vos conseils
Phil
Bonjour,
Suite à vos conseils, j'ai effectué la requete simple "select * from
articles where qte = 1 order by designation limit 15000,20" avec MySQL
Control Center 0.9.4-beta
Résultat : 20 rows en 0,11 sec. (vive MySQL !)
Ce test est effectué sur mon poste de dev en local, P4-2.6, RAM 1Go.
Jai fait mes premiers essais de LIMIT avec SQLManagerX (SQLTable)
avec cette requete, sans le where qte=1 (parcours de la table
articles, sans filtre, ordonné sur la clé designation) et j'avais
bien des ralentissements au fur et a mesure que j'avancais par PgDn
vers le bas de la table (instantané sur les premieres pages, mais
vers les enreg 60.000, il fallait environ 10 sec pour afficher la
page). Ces essais ont été fait sur portable PII-233, 196Mo de RAM, en
local. Et, dans ce cas, je ne passe pas par l'acces natif de PCSoft !
Donc, je ne comprends pas trop l'origine du probleme (vitesse proc,
mémoire, ... ????)
Pour revenir sur mes essais en cours: j'utilise l'acces natif de
PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
ligne" je fais des recherches sur 7 autres fichiers par
HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
RAM en local) et je pense que sur le reseau avec des clients moins
performants, ca ne va pas etre genial !
Merci encore pour tous vos conseils
Phil
Bonjour,
Suite à vos conseils, j'ai effectué la requete simple "select * from
articles where qte = 1 order by designation limit 15000,20" avec MySQL
Control Center 0.9.4-beta
Résultat : 20 rows en 0,11 sec. (vive MySQL !)
Ce test est effectué sur mon poste de dev en local, P4-2.6, RAM 1Go.
Jai fait mes premiers essais de LIMIT avec SQLManagerX (SQLTable)
avec cette requete, sans le where qte=1 (parcours de la table
articles, sans filtre, ordonné sur la clé designation) et j'avais
bien des ralentissements au fur et a mesure que j'avancais par PgDn
vers le bas de la table (instantané sur les premieres pages, mais
vers les enreg 60.000, il fallait environ 10 sec pour afficher la
page). Ces essais ont été fait sur portable PII-233, 196Mo de RAM, en
local. Et, dans ce cas, je ne passe pas par l'acces natif de PCSoft !
Donc, je ne comprends pas trop l'origine du probleme (vitesse proc,
mémoire, ... ????)
Pour revenir sur mes essais en cours: j'utilise l'acces natif de
PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
ligne" je fais des recherches sur 7 autres fichiers par
HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
RAM en local) et je pense que sur le reseau avec des clients moins
performants, ca ne va pas etre genial !
Merci encore pour tous vos conseils
Phil
OK mais tu compares 2 requetes différentes donc certainement avec 2 plan
d'accès en base différents. dans le 1er ta clause where oblige
MySQL à passer sur l'index et dans la 2ème il fait un access full surtout
aucun index existe sur désignation. Que donne la requete _SANS_ la clause
where ? Que donne l'explain de ces 2 requetes ?
> Pour revenir sur mes essais en cours: j'utilise l'acces natif de
> PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
> suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
> ligne" je fais des recherches sur 7 autres fichiers par
> HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
> a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
> comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
> RAM en local) et je pense que sur le reseau avec des clients moins
> performants, ca ne va pas etre genial !
Pourquoi ne pas tout faire en une seule requete ?
As-tu un exemple à m'envoyer (en PV) avec le script de création de base
(cela restera privé bien sur). Je regarderai si tu le veux bien.
OK mais tu compares 2 requetes différentes donc certainement avec 2 plan
d'accès en base différents. dans le 1er ta clause where oblige
MySQL à passer sur l'index et dans la 2ème il fait un access full surtout
aucun index existe sur désignation. Que donne la requete _SANS_ la clause
where ? Que donne l'explain de ces 2 requetes ?
> Pour revenir sur mes essais en cours: j'utilise l'acces natif de
> PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
> suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
> ligne" je fais des recherches sur 7 autres fichiers par
> HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
> a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
> comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
> RAM en local) et je pense que sur le reseau avec des clients moins
> performants, ca ne va pas etre genial !
Pourquoi ne pas tout faire en une seule requete ?
As-tu un exemple à m'envoyer (en PV) avec le script de création de base
(cela restera privé bien sur). Je regarderai si tu le veux bien.
OK mais tu compares 2 requetes différentes donc certainement avec 2 plan
d'accès en base différents. dans le 1er ta clause where oblige
MySQL à passer sur l'index et dans la 2ème il fait un access full surtout
aucun index existe sur désignation. Que donne la requete _SANS_ la clause
where ? Que donne l'explain de ces 2 requetes ?
> Pour revenir sur mes essais en cours: j'utilise l'acces natif de
> PCsoft, Table fichier pour parcourir la table ARTSERIE (20.000 enreg)
> suivant l'index NUMSERIE (clé alpha). Dans le code "affichage d'une
> ligne" je fais des recherches sur 7 autres fichiers par
> HLitRecherche(). Les trois premieres pages mettent environ 8 à 10 sec
> a s'afficher, les suivantes 1 sec (ce qui n'est pas tres "fluide"
> comme parcours). Ces resultat sont sur mon poste de dev (P4-2.6,1Go
> RAM en local) et je pense que sur le reseau avec des clients moins
> performants, ca ne va pas etre genial !
Pourquoi ne pas tout faire en une seule requete ?
As-tu un exemple à m'envoyer (en PV) avec le script de création de base
(cela restera privé bien sur). Je regarderai si tu le veux bien.
