Discussion :

[Lambrosx]

Bonsoir,
J'ai migré mon serveur MySQL de la version 4.0.14-nt en 5.0.37-community-nt.

Tout fonctionne visiblement bien sauf une application qui envoie une requete SQL à mon serveur qui le fait planter. Ca me prend 100% des ressources et ca ne s'arrete plus tant que je ne tue pas le processus. Je ne sais vraiment pas à quoi ca peut être du et je suis vraiment embeté. La requete qui fait planter le serveur semble relativement simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select distinct A.id_papier,A.id_type from bobine AS A,papier as B where A.id_papier=B.papier and A.id_type=B.type and A.id_client='64' and A.laize='44' and A.grammage LIKE '60' order by B.id_papier

Elle execute une jointure entre deux tables qui ont la structure suivante :
-papier :

id_papier int(11) NO PRI NULL auto_increment
papier int(11) NO 0
type int(11) NO 0
cache int(11) NO 0

-bobine:

id_operation int(2) unsigned NO PRI NULL auto_increment
date date NO 0000-00-00
grammage float NO 0
laize varchar(7) NO 0
id_papier int(1) NO 0
es int(11) NO 0
id_type int(11) NO 0
id_client int(4) NO 0
poid int(11) NO 0
tirage int(11) NO 0
poid2 int(11) NO 0
id_pagination int(11) NO 0
cah int(11) NO 0
commentaire blob NO
dossier int(6) NO 0
titre blob NO
cache int(11) NO 0
flagdebord int(11) NO 0
color int(11) NO 0
note blob NO
pagination text NO
poid_special int(11) NO 0

Y aurait il un problème lié à la différence de version et à ma requete? Peut-etre y a t-il une mise à jour à faire sur les fichiers qui contiennent les tables pour les rendre compatible avec la version 5? (Surprenant dans la mesure ou tous les autres programmes fonctionnes sans souci) La requete me semble vraiment normale.

Merci de votre aide.

[qi130]

Faudrait revoir les bases du SQL

1/ le mot réservé AS ne peut être utilisé qu'associé à 1 colonne ou 1 fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT SUM(...) AS TOTAL

par suite, la référence symbolique dans le from s'écrit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

...FROM BOBINE A...

2/ les valeurs dans la clause WHERE ne doivent pas être mises entre quote pour des colonnes numériques.
3/ le mot réservé LIKE ne s'applique qu'à des colonnes alphanumériques

[Lambrosx]

Ce n'est pas moi qui ait écrit cette requête et j'avoue ne pas avoir prêté attention aux erreurs de syntaxe hier soir. Mais le problème ne vient pas de la quoi qu'il en soit. J'ai toute fois essayé de corriger les erreurs de syntaxe pour en être sur et ca n'y change rien. J'ai ensuite testé ma requete en local sur mon installation EasyPHP qui utilise la version 5.0.24-community-log et la ca passe même avec la requete de base (sans modification syntaxique). Ca prouve bien que ca vient de ma version du serveur. Y aurait il une différence entre le binaire mysqld.exe et mysqld-nt.exe? Car je crois que c'est la seule différence que j'ai entre le serveur de production et mon serveur local.

Juste pour revenir aux problèmes de syntaxe, sauf erreur de ma part, l'utilisation du 'AS' est correcte même sur les noms de table. Pour preuve je peux donner un lien de la doc MySQL où un exemple en atteste :
http://dev.mysql.com/doc/refman/5.0/...nsitivity.html
Donc sauf incompréhension de ma part, je pense que tu te trompes.

Pour ce qui est du LIKE, celui ci peut s'appliquer à des colonnes numériques puisque c'est une extension MYSQL à la norme SQL92 comme en atteste une fois de plus la doc MySQL :

LIKE est possible avec des colonnes numériques.

http://dev.mysql.com/doc/refman/5.0/...s-to-ansi.html

Mais je suis d'accord avec toi qu'il est mieu de se référer à la norme!

Merci en tout cas pour ce début d'aide.

[Sivrît]

Les tables sont-elles grosses ? Et avec les même données partout ? Si c'est le cas, comme il semble que les tables ne sont pas indexées...

Il faudrait voir pour les deux bases ce que donnent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
EXPLAIN SELECT DISTINCT A.id_papier,A.id_type FROM bobine AS A,papier AS B WHERE A.id_papier=B.papier AND A.id_type=B.type AND A.id_client='64' AND A.laize='44' AND A.grammage LIKE '60' ORDER BY B.id_papier;
SELECT count(*) FROM bobine;
SELECT count(*) FROM papier;

Et en bonus peut-être:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SHOW INDEXES FROM bobine;
SHOW INDEXES FROM papier;
SHOW TABLE STATUS LIKE 'bobine';
SHOW TABLE STATUS LIKE 'papier';

[Lambrosx]

Aux dernières nouvelles, j'ai réussi à faire fonctionner mon serveur, mais je n'ai aucune excplication et reste un peu inquiet quant à l'avenir.
Comme je l'ai dit dans le post précédent, j'ai remarqué que la requete qui bloquait était correctement exécutée sur mon poste de développement équipé de la version 5.0.24.
Pour en avoir le coeur net, j'ai installé la version 5.0.37 sur mon post. La requete ne voulait de nouveau plus passé. J'ai alors remplacé le binaire mysqld.exe de la version 5.0.37 par celui de la version 5.0.24 et le problème a disparu de nouveau. Il y a donc visiblement une différence entre ces deux versions qui fait que ca plante avec mon environnement de travail SQL (tables...), mais je ne vois pas laquelle.

J'ai donc procédé aux mêmes modifications sur le serveur principal de production ce qui a résolu le problème également. La seule chose qui me chagrine pour l'instant, c'est que n'ayant pas de binaire nt de la version 5.0.24, j'utilise mysqld.exe. Mais j'ai lu que la version nt était plus optimisée niveau performance pour les environnements pro.

Je continue donc de chercher pour trouver ce qui n'allait pas. Il y a peut être quelque chose (une manipulation, configuration ou autre...) que je n'ai pas fait par rapport à la dernière version. Je trouve ca vraiment bizarre.

Les tables bobines et papier ont respectivement 24 488 et 4 920 entrées soit 2.1Mo et 122.7Ko.
Le moteur utilisé était en MyISAM. Les tables semblent être indexées (autoindexées peut être) via l'utilisation d'un BTREE. Je n'en suis pas sur n'était pas expert dans le domaine et n'ayant pas moi meme créer les bases.

Je vous remercie pour les réponses.

PS: Je laisse le post ouvert si des idées vous venaient.

[Sivrît]

Justement MySQL n'indexe à la base que les clefs primaires et les informations du post d'origine laissent penser que ça en est resté là. Or la jointure se fait sur "A.id_papier=B.papier AND A.id_type=B.type". D'où l'idée de voir si il y a des indexes en plus quelque part, si mysql les utilise pour ses requêtes etc...

Deux grosses tables et une jointure tordue sans indexation ça peut vite prendre pas mal de temps. Surtout que DISTINCT et ORDER BY n'aident pas. Cela dit ça devrait finir par aboutir Il y a peut-être vraiment un bug...


Juste un truc, la migration est bien passée par mysqldump ? Parce que

remplacé le binaire mysqld.exe de la version 5.0.37 par celui de la version 5.0.24

et utiliser les même fichiers de données ça m'inquète un peu.

[Lambrosx]

Pour ce qui est du transfert de données, j'ai essayé avec les deux et le résultat est le même.
Pour ce qui est des indexes, il faut que je cherche d'avantage car je ne suis pas callé en la matière. J'avoue que ca m'échappe un peu.
Mais je reste quand même étonné qu'entre Mysql 5.0.24 5.0.37, il y ait une différence au niveau de l'execution de ma requete. Du coup, est ce que ca vient de l'indexe?, je ne sais pas.
En tout cas, merci des réponses.