Discussion :

[mooztik]

bonjour,

voilà, j'ai ecris une requete multi-table qui fonctionne, mais cette derniere me parait 'lourde'.

J'aimerai donc des avis éclairés à ce sujet

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
SELECT 
		t.*, 
		s.serie_nom,		
		r.tracker_auth,
		f.team_name AS team_name,
		fb.team_name as team2_name,
		fc.team_name as team3_name,
		us.team_list,
		uc.*
		FROM at_users_selection as us, at_torrent as t, at_serie as s
		LEFT JOIN at_team as f ON f.team_id=t.team_id
		LEFT JOIN at_team as fb ON fb.team_id=t.team2_id
		LEFT JOIN at_team as fc ON fc.team_id=t.team3_id
		LEFT JOIN at_tracker as r ON r.tracker_id=t.tracker_id
		LEFT JOIN at_users_selection_config as uc ON uc.user_id='".$userdata['user_id']."'
		WHERE 
		us.user_id = '".$userdata['user_id']."'
		AND us.serie_id = t.serie_id
		AND t.serie_id = s.serie_id 
		AND ((t.torrent_validation='3') OR (t.torrent_validation='1'AND s.serie_auth='1') )
		AND t.torrent_date <= '".$time."' 
		AND f.team_validation='1'
		ORDER BY t.torrent_date 
		DESC 
		LIMIT 20

explain

Un grand merci par avance.

[Huntress]

Fais un EXPLAIN de cette requête, ça peut aider.

[mooztik]

voila

[Huntress]

Ben par exemple tu peux voir que la première ligne est un type ALL, et ça c'est mauvais, parce qu'il parcourt toute la table as-tu mis des INDEX ?

Quant à eq_ref et const, c'est bien et ref c'est moyen.

[Orionmel]

Tu devrais éviter les * déja. Si un jour tu rajoutes une colonne dans ces tables, elles seront ramenées dans ta requête même si elles ne t'interessent pas, d'où perte de temps

Sinon oui il faut créer des index sur les tables possèdant beaucoup d'enregistrements, ca accèlère pas mal les traitements

[mooztik]

toutes les tables ont un 'PRIMARY' pour la colonne 'xxxx_id' sauf la table 'at_users_selection ' qui ne peu pas l'etre.

pour le *, je l'es mis pour eviter la longue liste de reference, bien que pratiquement toutes les colonnes soient utilisées.

user_id est l index de reference sur de nombreuses tables, je l'utilise sur presque toutes les requetes.

n'empeche que j'ai l impression que cette requete peut etre optimisée.


et est il mieux d'inclure une table contenant la config utilisateur dans cette même requete ou faire 2 requetes séparées ? une pour la config et 1 pour la requete en elle même.

[Orionmel]

Une seule requête sera toujours plus optimisée que deux...

En effet il vaut mieux ramener tous les enregistrements qui t'interesse et les traiter en mémoire (un seul accés base donc un seul accès réseau lent et après des traitements en mémoire très rapide) plutôt que d'effectuer deux accès bases (le réseau est plus lent que la mémoire et l'interpréteur sql est obligé de compiler deux requêtes au lieu d'une).

Donc moi je suis partisant d'une bonne grosses requête (detoute façon tu vas pas manipuler des milliers d'enregistrements?) plutôt que deux petites.

[mooztik]

non y a pas de milliers d'enregistrements, en general ça ne depasse pas la 50ene de lignes de resultats.

donc telle quelle je peu pas vraiment mieux faire .

derniere question pratique

la table users_selection contient 3 colonnes qui font reference à user_id, serie_id et team_id. chaque ID fait reference à une table.
on peu avoir donc :
user_id | serie_id | team_id
-----------------------------------
2 15 8
2 24 7,15,24
4 15 NULL
4 24 15

mais pour chaque serie_id, il peu y avoir zero, un ou plusieurs team_id. pour le moment j utilise une concatenation pour pouvoir stocker en cas de plusieurs team_id (via une virgule en séparation des id).
ca me permet d'y voir clair et surtout d'eviter d avoir des lignes en doublon ou qui dépassent le nombre limite assigné.
mais du coup je me retrouve limité dans les possibilités de requetes, car mysql ne peu se baser sur cette concaténation pour rechercher dans la table team_id. je trafique via php en faisant le test de limitation avec un in_array, mais, ca allourdi inutilement à la fois le nombre de lignes en requete sql et le code php.
Sinon je doit passer par 2 requetes. une pour la selection utilisateur, puis ensuite pour la liste triée via cette selection.
donc je bloque totallement .
ma requete devant incorporer ce filtre supplémentaire.

si je fait autant de ligne que de team_id sélectionné, lors d'une modification de configuration de la part d un utilisateur, je me retrouve avec la necessité de faire plusieurs requetes sql (autant de team_id que l utilisateur à selectionné) lors d'une mise à jour. alors qu'actuellement je n'ai qu'une requete à faire pour la mise à jour.

j ai pensé passer via un type ENUM, mais le nombre d' id_team est variable.

je bloque là