Discussion :

[ocelote]

Bonjour, je rencontre un problème certainement du à une mauvaise optimisation de ma requete sql. En effet, celle-ci fonctionne quand la base de données est presque vide, et fait planter le serveur local lorsque beaucoup de champs sont à traiter.

Code :

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

1
2
3
4
5
 
SELECT SUM(DISTINCT t1.nb_p1) AS total_p1, SUM(DISTINCT t2.nb_p2) AS total_p2 
FROM t1
JOIN t2 ON t2.usine = t1.usine AND t2.datee BETWEEN '2009-01-02' AND '2010-03-04'
WHERE t1.usine = 'usine1' AND t1.datee BETWEEN '2009-01-02' AND '2010-03-04'

Le code parle de lui même. Merci pour votre aide éventuelle !

[punkoff]

Bonjour,

Le code ne parle pas de lui même.

Il faudrait que vous indiquiez votre sgbd, la définition de vos table, de vos index et la volumétrie traité.

[ocelote]

Je travaille sous MySQL
Dans cet exemple, on aurait 2 tables comportant 3 colonnes :

id-p1-usine-datee || id-p2-usine-datee

(respectivement INT (index)-INT-VARCHAR-DATE)

Les tables sont susceptible de comporter plusieurs centaines de milliers de champs.

Merci à toi

[punkoff]

Bonjour,

D'autre personne plus calé que moi en optimisation vont surement apporter une réponse plus exacte.

Ceci dit :
- Est-ce que le distinct sur vos sum est nécessaire ?
- Il faut que vous mettiez des indexs à minima sur vos jointure (usine).
- Si ceci ne suffit pas, il faudrait considérer le fait de rajouter des index sur vos clause de sélection voir sur votre sum.

edit: ne travaillant pas sur MySql je ne peux vous proposez que des axes de recherche que j'entreprendrai afin de voir si ca marche mieux.

[ocelote]

Merci beaucoup, je saisis l'importance des index désormais. Cela dit, je ne sais pas vraiment les utiliser. Directement dans ma base, j'ai ajouté un index sur "usine". Cependant, cela ne semble pas changer le problème. Ceci devrait fonctionner sans changer la requête ou bien faut-il le préciser quelque part d'utiliser cet index ?

PS edit : En créant l'index une taille m'est demandé, j'ai rien mis et la cardinalité est à 0. Bien entendu, les entrées ayant la meme "usine" sont nombreuses donc l'index a été ignoré ? sinon comment créer un index de cette utilité ?

Merci

[punkoff]

En ce qui concerne l'administration de votre base mysql je ne peux vous aider désolé.

Le problème de l'optimisation c'est que c'est un sujet vraiment très large, et qui est dépendant du sqgb / plateforme / modélisation que vous utilisez.

ici il y a un très bon article de sqlPro : http://dev.mysql.com/doc/refman/5.0/...l-indexes.html qui pose les bases.

Sinon ici un petit article sur les indexs et MySql : http://dev.mysql.com/doc/refman/5.0/...l-indexes.html


edit :

les entrées ayant la meme "usine" sont nombreuses donc l'index a été ignoré ?

Oui c'est une possibilité.

Si l'optimiseur force des scan de table à cause du nombre d'occurrence trop élevé, votre prochain ennemi sera : le distinct et la limitation de votre sgbd / plateforme à traiter beaucoup de donnée

[ocelote]

J'ai bien lu tout ça, je comprends mieux le problème de l'indexation.
Mais pour le moment je travaille avec 100 000 données (donc pas tant que ça) et j'ai toujours le message : 'server has gone away'

Si je fais des requêtes séparées, ce problème ne se pose meme pas, ce qui n'est pas si étrange apres tout. Que se passe-t-il réellement avec cette requête ? j'imagine que le JOIN sur 'usine' doit le faire réfléchir sachant que les deux tables contiennent 50 000 fois ce champ. Cependant pour avoir la somme que je veux, je ne vois pas comment l'éviter...

Je crois que le problème vient de la requête en elle même, qui agit sur le serveur comme une boucle trop longue (voir infini)

[punkoff]

Pardon je dois être mal réveillé ce matin

Quelle est la relation entre les 2 tables au niveau du champs "usine" (1-1, n-n, ?)

Car si on a 50k entrées usine1 dans t1 et 50k entrées usine1 dans t2 ça fait un gros paquet de résultats sur lesquels il faut faire un distinct (au final on va sélectionner 50k*50k lignes et faire un distinct la dessus)

edit : je ne sais pas si la syntaxe est correcet sous MySQL mais tentez quelque chose comme ceci :

Code :

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

1
2
3
4
5
6
7
8
SELECT 
(select SUM(DISTINCT t1.nb_p1) 
  from t1 
  where t1.usine = 'usine1' AND t1.datee BETWEEN '2009-01-02' AND '2010-03-04' and exists (select 1 from t2 where t1.usine = t2.usine)) AS total_p1,
(select SUM(DISTINCT t2.nb_p1) 
  from t2 
  where t2.usine = 'usine1' AND t2.datee BETWEEN '2009-01-02' AND '2010-03-04' and exists (select 1 from t1 where t1.usine = t2.usine)) AS total_p2
FROM DUAL

[ocelote]

C'est une relation n-n ...
J'ai supprimer les DISTINCT mais cela ne fonctionne toujours pas (en effet il ne sont pas indispensables)

Edit : je me penche sur votre proposition

[ocelote]

Pour ceux qui ont le probleme :

Code :

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

1
2
3
4
5
6
7
8
9
10
SELECT 
(SELECT SUM(DISTINCT t1.nb_p1) 
  FROM t1 
  WHERE t1.usine = 'usine1' AND t1.datee BETWEEN '2009-01-02' AND '2010-03-04' 
  AND t1.usine in (SELECT t2.usine FROM t2 WHERE t2.usine = 'usine1')) AS total_p1,
(SELECT SUM(DISTINCT t2.nb_p1) 
  FROM t2 
  WHERE t2.usine = 'usine1' AND t2.datee BETWEEN '2009-01-02' AND '2010-03-04' 
  AND t2.usine in (SELECT t1.usine FROM t1 WHERE t1.usine = 'usine1')) AS total_p2
FROM DUAL

bien vu

[punkoff]

Par contre vous dites au dessus que les distinct ne sont pas nécessaire, du coup dans cette requête non plus. Je les avais laissé car je ne sais pas quel type de sum vous faisiez.