requête qui tourne indéfiniment [Résolu]

[julien.63]

Salut,
Comme j'ai déjà eu l'occasion de le dire, je suis loin d'être un champion dans les requêtes.
En utilisant l'interface phpMyAdmin, j'essaie d'exécuter le code suivant :

Code :

1
2
3
4
5
6
7
8
SELECT COUNT(*)
FROM Tree
JOIN Stem USING (TreeID)
JOIN Measurement ON Measurement.StemID=Stem.StemID AND
Measurement.TreeID=Stem.TreeID
JOIN MeasurementAttributes ON
Measurement.MeasureID=MeasurementAttributes.MeasureID
WHERE Measurement.CensusID=6 AND MeasurementAttributes.TSMCode LIKE 'D%';

mais voilà la page se charge indéfiniment sans qu'aucun resultat ni aucun message d'erreur n'apparaissent...
j'ai essayé de passer les ON dans la clause WHERE mais idem...
Voyez-vous quelque chose de faux dans ma requête?

merci pour vos conseils

[Sivrît]

Ca a l'air d'aller... Il est possible de savoir si mysql rame, pour être certain que c'est un pb de performances ?

Tout ce que je vois c'est un problème d'indexes. Si les tables sont grosses et qu'il n'y a pas d'indexe les liaisons peuvent être (trop) couteuses. Que dit 'EXPLAIN' ? Quelles sont les tailles des tables ?

Sinon toutes les liaisons sont-elles indispensables pour juste comptrer des couples MeasurementAttributes-Measurement ? Est-ce qu'un 'Measurement.TreeID IS NOT NULL' ne suffirait pas ?

[julien.63]

Oui certaines tables ont pas mal d'enregistrements mais elles sont indexées.

Que dit 'EXPLAIN' ?

Code :

1
2
3
4
5
6
7
8
9
10
 
 TABLE  	 type  	 possible_keys  	 KEY  	 key_len  	 ref  	 rows  	 Extra
*********************************************************************************************************
Tree  	INDEX  	PRIMARY  	PRIMARY  	22  	NULL  	368122  	USING INDEX
**********************************************************************************************************
Stem  	ref  	PRIMARY  	PRIMARY  	4  	BCI.Tree.TreeID  	7708  	USING INDEX
***********************************************************************************************************
Measurement  	ref  	PRIMARY,TreeID,StemID,CensusID  	StemID  	11  	Stem.StemID  	10  	USING WHERE
***********************************************************************************************************
MeasurementAttributes  	range  	PRIMARY  	PRIMARY  	10  	NULL  	140744  	USING WHERE; USING INDEX

[Biglo]

Ta requête fait la même chose avec le client console ou bien une autre interface comme QueryBrowser ?

[Sivrît]

A supposer que le problème vienne effectivement de la requète plutôt que du client, une idée serait d'essayer par petit bout en ajoutant une table à chaque fois, pour localiser le problème. Et/ou en se limitant à un seul tree car il semble y en avoir énormément, histoire de valider que ça marche.

Il manquerait peut-être un indexe sur (Measurement.StemID, Measurement.TreeID), suivant la répartititon des enregistrements.
Ou même (Measurement.StemID, Measurement.TreeID, Measurement.CensusID) pour faire 'JOIN Measurement ON Measurement.StemID=Stem.StemID AND
Measurement.TreeID=Stem.TreeID AND Measurement.CensusID=6'

Autre idée, inverser l'ordre... même si faire un 'like' sur tous les 'MeasurementAttributes' n'est peut-être pas une bonne idée vu qu'ils doivent être très nombreux.

[julien.63]

Ta requête fait la même chose avec le client console ou bien une autre interface comme QueryBrowser ?

la base a été transféré sur un autre serveur plus costaud,
j'ai essayé directement dans mysql en ligne de commande sans passé par phpmyadmin, et c'est toujours pareil, donc il doit y avoir un schmurtz dans la conception de la base.

une idée serait d'essayer par petit bout en ajoutant une table à chaque fois, pour localiser le problème. Et/ou en se limitant à un seul tree car il semble y en avoir énormément, histoire de valider que ça marche.

je vais essayer...