Discussion :

[SQLpro]

EDIT : Quelles seraient les conséquences si je mettais des indexs partout ? Sur tous les champs de toutes les bases ? Ca surchargerait la base, ça finirait pas la ralentir ?

En comparaison, vous pourriez aussi emporter dans votre voiture, tous les types, dimensions et marque de roues de secours au cas ou... Mais il faudrait une sacrée remorque ! Pensez-vous que vous iriez plus vite ?
À lire : http://sqlpro.developpez.com/cours/quoi-indexer/

A +

[Xenofexs]

J'ai lu le lien que tu m'avais envoyé plus un doc pdf que tu as écris mais je reste un peu dans le flou du moins je ne sais pas exactement comment voir si mon index est utile ou pas ...

J'en ai testé plusieurs (en les supprimant après pour ne pas surcharger) mais je n'ai jamais gagné de temps pour cette maudite requête :

Code :

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

1
2
3
4
5
6
7
SELECT * FROM cc_inscription 
	LEFT JOIN cc_course ON cc_course.course_id = cc_inscription.course_id
	LEFT JOIN cc_utilisateur ON cc_inscription.utilisateur_id = cc_utilisateur.utilisateur_id
	LEFT JOIN cc_statut_coureur ON cc_statut_coureur.statut_coureur_id = cc_inscription.statut_coureur_id
	WHERE cc_course.course_relais != '1'
	AND cc_utilisateur.utilisateur_nom != '' 
	 ORDER BY cc_utilisateur.utilisateur_nom, cc_utilisateur.utilisateur_prenom,cc_inscription.inscription_date_rec DESC

Je pense qu'elle est un peu compliquée pour moi qui découvre les index

[aieeeuuuuu]

Bonjour,

En l’occurrence, avant de poser des index, il faut optimiser la requete en elle même.

Vous faites un SELECT *. Ceci diminue dans certains cas l’intérêt des index. Et des index qui pourrait être utiles, voire couvrants pourraient ne pas être utilisés. En effet, une fois les lignes rapidement "trouvées" grâce à l'index, le moteur doit aller chercher les lignes correspondantes dans la table afin de "récupérer" les valeurs des autres colonnes.
Commencez-donc par spécifier explicitement le nom des colonnes qui vous sont utiles.

Ensuite, pourquoi des jointures externes ? surtout qu'ensuite vous placez des filtres qui annuleront de toute façon l'effet de cette jointure externe...

De plus, étant donnée la nature de vos filtres ( UneColonne <> UneValeure), il est peu probable qu'un index puisse être efficace, à moins que vous n'ayez une répartition très particulière des données, ou que vous ne fassiez un index filtré (mais à ma connaissance, MySQL ne permet pas cela).

Par ailleurs, quel est le type de la colonne cc_course.course_relais ? si c'est un type numérique, alors enlevez les guillemets dans votre filtre.

[Xenofexs]

Oui je sais tout ça mais je préférai laisser la requête originale plutôt que la modifier. Mais si aucun index n'est possible sans une refonte, je la referai demain

Je vous tiens au courant, encore merci pour votre aide et bonne soirée


EDIT : Bon, voila, j'ai refait la requête et maintenant tout va pour le mieux. Cependant j'aurai bien essayé de déterminer les indexs pour m'entrainer et apprendre (le but de ce topic à la base )

De plus, je remarque une différence de 4 personnes entre ma requête et celle originale (sur +7600 résultats) et je ne comprends pas trop pourquoi

Voici ma requête

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT 	inscription_id, cc_inscription.utilisateur_id, cc_inscription.course_id, cc_inscription.inscription_statut_id, validation_licence_id, 
									validation_certificat_id, cc_inscription.statut_coureur_id, course_package_id, espere_temps, inscription_date_rec, 
									inscription_mail_statut, inscription_certificat_medical, inscription_licence_num, inscription_club_num, inscription_equipe, 
									inscription_equipe_nom, statut_coureur_nom, inscription_statut_titre
FROM cc_inscription, cc_course, cc_utilisateur, cc_statut_coureur, cc_inscription_statut
WHERE 1=1
AND cc_inscription.utilisateur_id = cc_utilisateur.utilisateur_id
AND cc_inscription.course_id = cc_course.course_id
AND cc_inscription.statut_coureur_id = cc_statut_coureur.statut_coureur_id
AND cc_inscription.inscription_statut_id = cc_inscription_statut.inscription_statut_id
AND cc_course.course_relais !=1
AND cc_utilisateur.utilisateur_nom !=""

[aieeeuuuuu]

De plus, je remarque une différence de 4 personnes entre ma requête et celle originale (sur +7600 résultats) et je ne comprends pas trop pourquoi

C'est certainement dû à vos jointures internes .
Je demandais leur utilité (car certaines étaient clairement inutiles du fait du filtre). Mais pour certaines tables, elles sont peut-être justifiées !

A ce propos... Il y a une table en plus dans cette nouvelle requete...

Voici ma requête

Vous avez fait un grand pas... en arrière
depuis plus de 20 ans maintenant les jointures, même internes, s'écrivent avec INNER JOIN.
Par ailleurs, pour des raisons de lisibilité, vous devriez utiliser des alias pour vos noms de table
Votre requete devrait donc plutôt ressembler à 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
24
25
26
27
28
29
30
31
32
33
34
 
SELECT 	
			inscription_id
		,	ins.utilisateur_id
		,	ins.course_id
		,	ins.inscription_statut_id
		,	validation_licence_id
		,	validation_certificat_id
		,	ins.statut_coureur_id
		,	course_package_id
		,	espere_temps
		,	inscription_date_rec
		,	inscription_mail_statut
		,	inscription_certificat_medical
		,	inscription_licence_num
		,	inscription_club_num
		,	inscription_equipe
		,	inscription_equipe_nom
		,	statut_coureur_nom
		,	inscription_statut_titre
FROM		cc_inscription ins
INNER JOIN	cc_course crs
	ON		cc_crs.course_id = ins.course_id
INNER JOIN	cc_utilisateur uti
	ON		ins.utilisateur_id = uti.utilisateur_id
LEFT JOIN	cc_statut_coureur stc
	ON		stc.statut_coureur_id = ins.statut_coureur_id
LEFT JOIN	cc_cc_inscription_statut ist
	ON		ins.inscription_statut_id = ist.inscription_statut_id
WHERE 		crs.course_relais <> '1'
	AND	uti.utilisateur_nom <> '' 
ORDER BY	uti.utilisateur_nom
	,	uti.utilisateur_prenom
	,	ins.inscription_date_rec DESC

[Xenofexs]

Pour les alias non, car je ne suis pas le seul à bosser dessus et des conditions viennent se rajouter via des variables php (genre le order by) et je ne peux pas changer tout le fichier.
Pour la table supplémentaire, effectivement en refaisant la requête et parcourant le fichier php, j'ai vu qu'avant il manquait une info utilisée plus bas dans le code

Plutôt que de me railler j'apprécierai d'avoir plus d'infos. J'ai fait cette requête comme je l'ai appris, que ça ait 20 ans de retard n'est pas ma faute.

Merci en tout cas pour la réponse je vais regarder plus en détail le coup des INNER JOIN.

[aieeeuuuuu]

Désolé si je vous ai froissé, là n'étais point le but, juste une note d'humour car votre requete à plutôt regrssé : Vous avez profondément modifié votre requete au niveau des jointures, alors qu'il suffisait de remplacer vos LEFT par des INNER (ou même tout simplement supprimer vos LEFT, INNERétant facultatif, et par défaut). A coté de ça vous n'avez pas modifié vos filtres, c'était pourtant mineure (certes ça n'apporte rien aux performances)
De plus, l'ajout explicite des colonnes est une bonne chose, mais avec une bonne indentation c'est tout de même beaucoup plus lisible, ce qui est fort pratique lorsqu'on doit placer les bons index pour une requete...
Enfin, vous indiquez vouloir plus d'infos, mais vous ne précisez pas lesquelles... difficile donc de vous aider plus !

[Xenofexs]

J'ai pour ma part, réagit un peu puérilement à votre réponse.

En explication je pense que c'est surtout à moi de lire de mon coter sur les INNER et autres joyeuseté (je n'ai jamais utilisé que ce que j'ai montré dans ma requête; jamais de LEFT JOIN ou d'INNER JOIN ou autre truc étrange pour moi ^^). Surtout que je ne vois pas l'intéret des INNER JOIN par rapport à ma méthode (qui d'ailleurs s'exécute environ 2 fois plus vite que la votre) mais je comprendrai peut être après mettre mieux renseigné.

Bon du coup, la requête ne prends que quelques millisecondes donc plus la peine de créer des indexs, même si j'aurai bien aimé en faire pour avoir un exemple plus tard.

Mais sinon, le problème est résolu Je le noterai résolu ce soir ou demain au cas où il y aurait d'autres remarques