pb de jointures (?) mysql - Page 1

voilà, j'ai une première table "heuristiques" avec comme champs instance, temps, resultat et une seconde table "instances" avec comme champs instance, n

je voudrais faire une requête mysql qui renvoie tous les résultats d'heuristiques tels que temps=100 et utilisants les instances avec n=100

quelque chose qui fasse en gros
'SELECT resultat FROM heuristiques WHERE heuristiques.temps=100 AND instances.n = 100 AND heuristiques.instance = instances.instance'

Je sais que je pourrais faire SELECT resultat FROM heuristiques WHERE temps = 100 AND heuristiques.instance IN (SELECT instances.instance FROM instances WHERE instances.n=100)

mais cette dernière syntaxe ne me convient pas #chieur#

oui, je sais que je suis un gros ni00b en sql, mais j'assume farpaitement

SELECT heuristiques.resultat FROM instances, heuristiques WHERE heuristiques.temps=100 AND instances.n = 100 AND heuristiques.instance = instances.instance
ca fait longtemps que j'ai pas fait de SQL, mais ca marche pas ca ?

bah à priori si

ou bien

SELECT heuristiques.resultat
FROM heuristiques
INNER JOIN instances ON instance.instance=heuristiques.instance
WHERE heuristiques.temps=100 AND instances.n = 100

ok, merci, je vais pouvoir tester tout ça

effectivement, ça marche, j'ai dû merdouiller quelque part
merci
pendant que j'y suis, encore une question

j'aimerai faire
mysql_query('SELECT DISTINCT methode FROM heuristiques WHERE temps = 100 AND heuristiques.instance IN (SELECT instances.instance FROM instances WHERE instances.n=100) ', $db)
mysql_query('SELECT DISTINCT approximation FROM heuristiques WHERE temps = 100 AND heuristiques.instance IN (SELECT instances.instance FROM instances WHERE instances.n=100) ', $db)
mysql_query('SELECT resultat FROM heuristiques WHERE temps = 100 AND heuristiques.instance IN (SELECT instances.instance FROM instances WHERE instances.n=100) ', $db )

mais du coup, ça revient à faire 3 fois la requête 'SELECT instances.instance FROM instances WHERE instances.n=100'
y a pas moyen de la sauvegarder dans une variable temporaire ?

non pas moyen.

au mieux, le SGBD fera l'optimisation tout seul.

Par contre, tu peux à priori faire les 3 requêtes sans avoir recours à une sous requete, ce qui est mieux pour l'optimisation.
(les IN ; NOT IN c'est pas ce qu'il y a de plus rapide)

comment ça, faire les 3 requêtes sans sous-requêtes ?

tu as mis ça:

SELECT DISTINCT methode FROM heuristiques WHERE temps = 100 AND heuristiques.instance IN (SELECT instances.instance FROM instances
WHERE instances.n=100

Je suggère:

select distinct methode
from heuristiques h,instances i
where
h.instance=i.instance
and h.temps=100
and i.n=100

ok, merci. il y a une raison particuilière pour laquelle ça optimise mieux ?

Tu peux toujours copier la table dans une table en RAM (type HEAP à choisir lors de la création de la table) et non sur disque s'il ne risque pas d'y avoir de modifications critiques sur la table d'origine. Ca peut te permettre d'avoir une plus grande réactivité, mais ça n'est intéressant que s'il y a énormément d'accès, si c'est une table principalement en lecture... et il faut la reconstruire à chaque redémarrage du serveur mySQL. Ca ne répond pas forcément à ta demande, mais ça peut être une solution en cas d'accès en nombre.

Par rapport à l'optimisation de Microbug, c'est simplement que ce qui est le plus long dans une table, c'est le SELECT. Si tu fais un SELECT imbriqué, tu ralentis ton opération. D'ailleurs, quand on fait du relationnel, on évite au maximum les requêtes imbriquées.

Nil :
Tu peux toujours copier la table dans une table en RAM (type HEAP à choisir lors de la création de la table) et non sur disque s'il ne risque pas d'y avoir de modifications critiques sur la table d'origine. Ca peut te permettre d'avoir une plus grande réactivité, mais ça n'est intéressant que s'il y a énormément d'accès, si c'est une table principalement en lecture... et il faut la reconstruire à chaque redémarrage du serveur mySQL. Ca ne répond pas forcément à ta demande, mais ça peut être une solution en cas d'accès en nombre.

y a en moyenne un accès toutes les 10 min le problème, c'est que chaque accès va renvoyer des de milliers de réponses (pour l'instant, mais ça va grossir à qqes dizaines de millers je pense)
après, pour la table en RAM, je pourrais sûrement faire ça
merci

ce qui justifie mon optimisation d'après moi, c'est aussi le IN avec une sous requete qui est lent... très lent.
Surtout quand il commence à y avoir pas mal de lignes dans les tables, comme ça semble être ton cas.

je vais tester les deux pour comparer

10000, c'est peu, pour une base de données.

je passe de 80s à 9s, effectivement, y a un gain

merci !!!!!!!!


moumou > c'est un pauvre proc à 1GHz avec même pas 1Go de ram et plein d'applis qui tournent en même temps dessus (et 80s de traitement, ça commençait à faire beaucoup )

ok

80s !

J'ai pas suivi si tu l'avais déjà dit, mais le moteur de SGBD, c'est mysql ? Même 9s avec 10 000 lignes ça me semble énorme.
Il y a des index qui vont bien sur tes tables ?

Enfin, je dis ça mais je suis probablement un peu déformé par les bases Oracle du boulot qui sont plutôt performantes... MySQL a encore du chemin à faire.

euh ... mysql est très performant hein.

cf http://www.wikipedia.org par exemple

Je dis pas que c'est pas performant, je dis que je suis étonné par les temps qu'annonce Flanker

Après, peut-être qu'il n'a pas d'index, que la machine sur laquelle tourne son mysql n'est pas au top, que plein de choses...

Et même si Mysql est très performant dans la majorité des cas, ils ont encore du chemin à faire pour se développer en entreprise (j'entends par la sur un autre créneau que celui des sites web).

D'ailleurs Flanker, si tu pouvais m'envoyer tes requêtes et ton jeu de donnée, je viens d'installer un MySQL 5 et je voudrais comparer un peu les perfs.

'rci

Je pense que mysql est peu développé en entreprises plus par manque de features que par manque de performances brutes pour les choses qu'il sait faire.

ok, je vais faire ça

mais pour les index, a priori j'en ai pas, en tout cas je n'ai rien fait pour (oui, je n'ai suivi aucun cours de bdd et j'ai pas suivi non plus de tuto ^^)

ah ben alors c'est normal que ça marche pas

bah si ça marche, c'est juste très lent

Les index permettent d'accéder plus rapidement aux données.
En général, elles sont stockées sous forme d'arbres (mais ça dépend des SGBD) indexés par des clés.
Quand tu crées une table, elle est stockée en utilisant la clé primaire comme index.
Mais tu peux rajouter des index sur d'autres champ, s'ils sont souvent sollicités dans les clauses WHERE de tes requêtes, ça accélérera le temps de recherche des lignes correspondantes.

oui mais si il n'a pas non plus défini de clé, ben y a pas d'index non plus. (oui y a deux fois non plus, mais c'est normal, chacun a son sens dans la phrase ^^)

Il y a forcément une clé primaire, non ?