Jointure VS Select

8 réponses

Auteur	Message
mirage \| Modérateur Inscrit le : 04/05/2005	# Le 13/04/2007 à 18:09 Hop, J'ai des données éparpillées sur plusieurs tables (8 pour être exact) et je voulais savoir s'il faut mieux faire une jointure ou plusieurs select (pour récupérer un seul résultat) ? J'ai fait un explain de ma jointure et ça semble ne pas être trop difficile à traiter pour mySQL (0.0054 sec. pour le traitement de l'EXPLAIN d'après phpMyAdmin) car c'est assez bien indexé : id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE a const PRIMARY,... PRIMARY 4 const 1 1 SIMPLE b const PRIMARY PRIMARY 4 const 1 1 SIMPLE c const PRIMARY PRIMARY 4 const 1 1 SIMPLE d const PRIMARY PRIMARY 4 const 1 1 SIMPLE e const PRIMARY PRIMARY 2 const 1 1 SIMPLE f const PRIMARY,... PRIMARY 4 const 1 1 SIMPLE g const PRIMARY PRIMARY 2 const 1 Actuellement, les tables concernées ne sont pas très remplies (quelques dizaines de milliers d'enregistrements au maximum) mais il devrait y en avoir plusieurs centaines de milliers au final. Donc en gros, faut-il mieux faire plusieurs jointures (si tout est bien indexé, je dirais que oui mais je n'en suis pas sur) ou bien plusieurs select ? Marchi NB : J'ai réussi à ne pas casser le forum, je suis content
jdelire \| Lilian Membre Inscrit le : 14/05/2005	# Le 13/04/2007 à 18:39 NB : J'ai réussi à ne pas casser le forum, je suis content Raté, pas sous ie Slwo.fr
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 13/04/2007 à 18:40 jdelire a dit : Raté, pas sous ie Je parle des navigateurs, pas du reste
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 13/04/2007 à 18:40 Je ferais une seule jointure, c'est mieux digéré par mySQL et pour maintenir le code je trouve ça plus simple, en cas de modification d'une ou plusieurs tables par exemple. mirage a dit : NB : J'ai réussi à ne pas casser le forum, je suis content FAUX ! Sous IE 7 c'est dégueu Feu d'artifice Paris
Shain \| Yoann Membre Inscrit le : 10/05/2005	# Le 13/04/2007 à 19:55 Pour moi, les SGBD sont optimisés pour gérer les jointures (c'est leur job après tout) donc à mon avis il vaut mieux travailler avec des jointures qu'avec du SELECT à outrance. Pense à utiliser les LEFT JOIN, c'est bien plus performant que les jointures par id dans une clause WHERE. [ Shain ] http://www.automobile-propre.com - http://fr.chargemap.com
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 13/04/2007 à 20:00 Une jointure sur 8 tables, contenant pour certaines des centaines de milliers de lignes, ca me parait tout de meme tendu... Le risque est que la jointure ne puisse pas se faire en mémoire à cause de la volumétrie. Et la, les performances deviennent catastrophiques. Et ca lock les 8 tables pendant toute la durée de la requete. Le 0.0054 sec ne serait pas un temps de reponse d'une requete en cache ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 13/04/2007 à 20:59 devtribu a dit : Le 0.0054 sec ne serait pas un temps de reponse d'une requete en cache ? Effectivement, en rajoutant "SQL_NO_CACHE" dans la requête, ça passe à 0.0442. Les données seront mises en cache donc les requêtes ne seront pas effectuées toutes les secondes, ça devrait être correct. Le problème c'est que ce n'est pas facile d'améliorer la structure des tables car il y a trop de critères nécessitants des id uniques en provenances de tables...
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 13/04/2007 à 22:51 J'ai des données éparpillées sur plusieurs tables (8 pour être exact) et je voulais savoir s'il faut mieux faire une jointure ou plusieurs select (pour récupérer un seul résultat Dans le cas d'Oracle sur une énorme base (certaines tables contenant des dizaines de millions d'enregistrement), les deux cas se présentaient selon les cas. On avait des requetes contenant une dizaine de vues imbriquées (c'est à dire de nombreux select imbriqués, avec jointures dans tous les sens) qui étaient parfois plus rapide que la méthode "X tables temporaires".... et parfois c'était tout le contraire... Bref, pas de règle absolue de ce coté, le volume de données, les indexes et l"optimiseur" interne du SGBD feront la différence. PS : oui mon post ne sert à rien Pense à utiliser les LEFT JOIN, c'est bien plus performant que les jointures par id dans une clause WHERE. mmm généralement c'est tout le contraire.... et puis de toutes façons ça ne retourne pas du tout le même résultat, donc bof. daevel : infogérance et conseil \|\| moi
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 15/04/2007 à 22:21 Je me trompe peut être, mais les LEFT JOIN, c'est à priori pour pouvoir faire en acceptant qu'il n'y ait pas de correspondance, les colonnes concernées valent alors null. Moi je te dirais sans hésitation, joint tout. 8 jointures, c'est pas la mort, par contre, faut surtout pas se planter dans les index. Et prévoi aussi que le buffer d'index de MySQL puisse contenir la taille de tous index (concernés par ta jointure) réunis. Perso, j'ai déjà eu à faire des jointures multiples (c'était pas vraiment comparable vu que je joignais plusieurs fois la même table mais à des endroits différents) et c'était toujours plus rapide que plusieurs SELECT. Ne serait-ce que parce que dans ce cas là, c'est PHP qui s'en occupe, et ça ralentit forcément. Hum, en fait je vois que j'arrive après la bataille... Florent Clairambault - http://florent.clairambault.fr Gtalk : superfc@gmail.com

Auteur

Message

Inscrit le : 04/05/2005

# Le 13/04/2007 à 18:09

Hop,

J'ai des données éparpillées sur plusieurs tables (8 pour être exact) et je voulais savoir s'il faut mieux faire une jointure ou plusieurs select (pour récupérer un seul résultat) ?

J'ai fait un explain de ma jointure et ça semble ne pas être trop difficile à traiter pour mySQL (0.0054 sec. pour le traitement de l'EXPLAIN d'après phpMyAdmin) car c'est assez bien indexé :

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra

1 	SIMPLE 	a 	const 	PRIMARY,... 	PRIMARY 	4 	const 	1

1 	SIMPLE 	b 	const 	PRIMARY 	PRIMARY 	4 	const 	1

1 	SIMPLE 	c 	const 	PRIMARY 	PRIMARY 	4 	const 	1

1 	SIMPLE 	d 	const 	PRIMARY 	PRIMARY 	4 	const 	1

1 	SIMPLE 	e 	const 	PRIMARY 	PRIMARY 	2 	const 	1

1 	SIMPLE 	f 	const 	PRIMARY,... 	PRIMARY 	4 	const 	1

1 	SIMPLE 	g 	const 	PRIMARY 	PRIMARY 	2 	const 	1

Actuellement, les tables concernées ne sont pas très remplies (quelques dizaines de milliers d'enregistrements au maximum) mais il devrait y en avoir plusieurs centaines de milliers au final.

Donc en gros, faut-il mieux faire plusieurs jointures (si tout est bien indexé, je dirais que oui mais je n'en suis pas sur) ou bien plusieurs select ?

Marchi

NB : J'ai réussi à ne pas casser le forum, je suis content

jdelire | Lilian
Membre

Inscrit le : 14/05/2005

# Le 13/04/2007 à 18:39

NB : J'ai réussi à ne pas casser le forum, je suis content

Raté, pas sous ie

Slwo.fr

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 13/04/2007 à 18:40

jdelire a dit :
Raté, pas sous ie

Je parle des navigateurs, pas du reste

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 13/04/2007 à 18:40

Je ferais une seule jointure, c'est mieux digéré par mySQL et pour maintenir le code je trouve ça plus simple, en cas de modification d'une ou plusieurs tables par exemple.

mirage a dit :
NB : J'ai réussi à ne pas casser le forum, je suis content

FAUX !

Sous IE 7 c'est dégueu

Feu d'artifice Paris

Shain | Yoann
Membre

Inscrit le : 10/05/2005

# Le 13/04/2007 à 19:55

Pour moi, les SGBD sont optimisés pour gérer les jointures (c'est leur job après tout) donc à mon avis il vaut mieux travailler avec des jointures qu'avec du SELECT à outrance.

Pense à utiliser les LEFT JOIN, c'est bien plus performant que les jointures par id dans une clause WHERE.

[ Shain ]
http://www.automobile-propre.com - http://fr.chargemap.com

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 13/04/2007 à 20:00

Une jointure sur 8 tables, contenant pour certaines des centaines de milliers de lignes, ca me parait tout de meme tendu...

Le risque est que la jointure ne puisse pas se faire en mémoire à cause de la volumétrie. Et la, les performances deviennent catastrophiques. Et ca lock les 8 tables pendant toute la durée de la requete.

Le 0.0054 sec ne serait pas un temps de reponse d'une requete en cache ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 13/04/2007 à 20:59

devtribu a dit :
Le 0.0054 sec ne serait pas un temps de reponse d'une requete en cache ?

Effectivement, en rajoutant "SQL_NO_CACHE" dans la requête, ça passe à 0.0442. Les données seront mises en cache donc les requêtes ne seront pas effectuées toutes les secondes, ça devrait être correct.

Le problème c'est que ce n'est pas facile d'améliorer la structure des tables car il y a trop de critères nécessitants des id uniques en provenances de tables...

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 13/04/2007 à 22:51

J'ai des données éparpillées sur plusieurs tables (8 pour être exact) et je voulais savoir s'il faut mieux faire une jointure ou plusieurs select (pour récupérer un seul résultat

Dans le cas d'Oracle sur une énorme base (certaines tables contenant des dizaines de millions d'enregistrement), les deux cas se présentaient selon les cas.

On avait des requetes contenant une dizaine de vues imbriquées (c'est à dire de nombreux select imbriqués, avec jointures dans tous les sens) qui étaient parfois plus rapide que la méthode "X tables temporaires".... et parfois c'était tout le contraire...

Bref, pas de règle absolue de ce coté, le volume de données, les indexes et l"optimiseur" interne du SGBD feront la différence.

PS : oui mon post ne sert à rien

Pense à utiliser les LEFT JOIN, c'est bien plus performant que les jointures par id dans une clause WHERE.

mmm généralement c'est tout le contraire.... et puis de toutes façons ça ne retourne pas du tout le même résultat, donc bof.

daevel : infogérance et conseil || moi

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 15/04/2007 à 22:21

Je me trompe peut être, mais les LEFT JOIN, c'est à priori pour pouvoir faire en acceptant qu'il n'y ait pas de correspondance, les colonnes concernées valent alors null.

Moi je te dirais sans hésitation, joint tout. 8 jointures, c'est pas la mort, par contre, faut surtout pas se planter dans les index. Et prévoi aussi que le buffer d'index de MySQL puisse contenir la taille de tous index (concernés par ta jointure) réunis.

Perso, j'ai déjà eu à faire des jointures multiples (c'était pas vraiment comparable vu que je joignais plusieurs fois la même table mais à des endroits différents) et c'était toujours plus rapide que plusieurs SELECT. Ne serait-ce que parce que dans ce cas là, c'est PHP qui s'en occupe, et ça ralentit forcément.

Hum, en fait je vois que j'arrive après la bataille...

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.