Discussion :

[Invité]

Bonjour, Bonsoir

Ma requête fonctionne correctement mais j'aimerais savoir si il est possible de diminuer le temps d’exécution.

Lorsque j'utilise aucun ORDER BY, c'est extrêmement rapide 0.016 sec.
Par contre avec un ORDER BY sur un datetime je suis à 0.312 sec et je suis OBLIGÉ de l'utiliser.

Vous allez peut être me dire que c'est normal mais je trouve ça énorme car c'est seulement sur 10737 résultats.
Avec un EXPLAIN, je vois bien que ma requête utilise une table temporaire (pour un DISTINCT) et un filesort (pour mon ORDER BY). C'est surement ce filesort qui prend du temps car le reste de la requête est déjà optimisé au mieux.
J'ai quand même 13 jointures sur la tables mais bon elles sont toutes correctes (voir l'explain, j'ai remplacé le nom de mes fk par moi)

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
1	SIMPLE	E	ALL	PRIMARY...			10737	Using where; Using temporary; Using filesort
1	SIMPLE	EG	ref	PRIMARY PRIMARY	8	moi	1	Using index; Distinct
1	SIMPLE	G	eq_ref	PRIMARY	PRIMARY	3	moi	1	Distinct
1	SIMPLE	SF	eq_ref	PRIMARY	PRIMARY	3	moi	1	Using where; Distinct
1	SIMPLE	F	const	PRIMARY	PRIMARY	1	moi	1	Using index; Distinct
1	SIMPLE	EA	ref	PRIMARY	PRIMARY	8	moi	1	Using index; Distinct
1	SIMPLE	A	eq_ref	PRIMARY	PRIMARY	4	moi	1	Using index; Distinct
1	SIMPLE	V	eq_ref	PRIMARY	PRIMARY	3	moi	1	Distinct
1	SIMPLE	D	eq_ref	PRIMARY	PRIMARY	1	moi	1	Distinct
1	SIMPLE	R	eq_ref	PRIMARY	PRIMARY	1	moi	1	Using index; Distinct
1	SIMPLE	S	eq_ref	PRIMARY	PRIMARY	3	moi	1	Using index; Distinct
1	SIMPLE	LA	eq_ref	PRIMARY	PRIMARY	1	moi	1	Using index; Distinct
1	SIMPLE	LA2	eq_ref	PRIMARY	PRIMARY	1	moi	1	Using index; Distinct
1	SIMPLE	T	eq_ref	PRIMARY	PRIMARY	4	moi	1	Using where; Distinct
1	SIMPLE	TE	const	PRIMARY	PRIMARY	4	const	1	Using index; Distinct
1	SIMPLE	H	ref	cle_etrangere	8	ref	1	Using index; Distinct

Ma requête ressemble à ceci :

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
SELECT SQL_NO_CACHE STRAIGHT_JOIN 
DISTINCT(colonne) 
FROM table E 
INNER JOIN table EG using (clé_primaire) 
INNER JOIN table G using (clé_primaire) 
INNER JOIN table SF using (clé_primaire) 
INNER JOIN table  F using (clé_primaire)
LEFT JOIN table EA using (clé_primaire) 
LEFT JOIN table A using (clé_primaire)	
LEFT JOIN table V using (clé_primaire) 
LEFT JOIN table D using (clé_primaire) 
LEFT JOIN table R using (clé_primaire)
LEFT JOIN table S using (clé_primaire)
LEFT JOIN table LA ON (D.clé_primaire) = (LA.clé_primaire)
LEFT JOIN table LA2 ON (V.clé_primaire) = (LA2.clé_primaire)	
LEFT JOIN table T using (clé_primaire)
LEFT JOIN table TE using (clé_primaire)
LEFT JOIN table H using (clé_primaire) 
WHERE F.clé_primaire=1 
AND T.clé_primaire= 2
AND E.DATETIME > date_sub(CURDATE(), interval 1 day) 
ORDER BY E.DATETIME DESC
LIMIT 20

Dans un premier temps j'ai essayé de créer un index sur ma colonne Datetime pour voir mais c'est encore pire...
Précision : mes id sont bien unsigned , par contre mon id principal de ma table est un BigInt
Auriez vous une solution à proposer ?

[punkoff]

bonjour,

l'index que vous avez testé était de cette forme ? : colonne_date desc, colonne_jointure

[Invité]

salut punkoff,

non j'ai juste testé un index simple sur la colonne de la date. J'essaye cela à mon retour. Tu peux me préciser ce que tu entends par colonne_jointure ?
toutes les colonnes ?

[punkoff]

les colonnes de jointures, pour cette requete.

[SQLpro]

MySQL (comme PostGreSQL mais dans une moindre mesure) dispose d'un moteur de requête très limité en matière de jointure. Au delà d'une demi douzaine de jointure l'optimiseurs est incapable de s'en sortir correctement.. (pour PG la limite est à 12...).

Si vous savez une base de données pour lequel vous aurez constamment ce genre de requête, alors passez à Oracle ou SQL Server, qui savent optimisez des dizaines de jointures sans aucun problème....

Ce n'est pas pour rien que fabriquer un SGBDR, et notamment la partie optimisation c'est plus de 800 années/hommes en R&D...

A +

[Invité]

@punkoff ; j'ai bien fait un index sur deux colonnes mais c'est pas mieux , c'est même moins bien 0.483 sec. J'avoue pas bien comprendre pourquoi c'est plus long.

@SQLpro : cela m'est passé par la tête. Il me fallait une raison pour passer à un moteur plus pro et je crois bien que je l'ai trouvé.

Merci pour vos réponses.