Discussion :

[Manu0086]

Bonjour,

Dans le fichier slow-query.log, j'ai une requête qui semble poser des problèmes.

# Time: 060309 16:54:10
# Query_time: 7 Lock_time: 0 Rows_sent: 100 Rows_examined: 279444
use footlandv2off;
SELECT joueurs.id,joueurs.nom,joueurs.equipe,equipes.nom,amicaux,coupes,champ FROM joueurs,equipes,buteurs WHERE joueurs.equipe = equipes.id AND buteurs.id = joueurs.id AND (amicaux+coupes+champ) != 0 ORDER BY (amicaux+coupes+champ) DESC, joueurs.nom ASC LIMIT 0,100;

C'est un classement des meilleurs buteurs tous matchs confondus.
Comme vous verrez, il y a trois tables nécessaires.
La table principale est la table "buteurs" avec les champs "amicaux", "coupes" et "champ".

Voyez-vous une solution pour optimiser cette requète sachant que j'ai besoin pour l'affichage de récupérer le nom du joueur, le nom de l'équipe et son nombre de but ?


PS : je viens de voir une optimisation possible en regroupant les champs amicaux,coupes et champ à la table des joueurs. Si vous voyez une meilleure optimisation, merci.

[tib1664]

Est-ce que tu as des indexes sur les clés secondaires?

Tu peux aussi mettre des indexes sur les champs un peu lourds en taille.

[pcaboche]

tib1664: +1


J'imagine que la table "buteurs" a la cardinalité la plus faible. Si tu commençais par elle dans ton FROM?

Code :

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

FROM buteurs,joueurs,equipes

Et si tu utilisais des INNER JOIN histoire de mettre de l'ordre?

Enfin "(amicaux+coupes+champ) != 0" se simplifie par "(amicaux+coupes+champ)" ou même par "(amicaux OR coupes OR champ)" puisque la somme est toujours positive (mais là, c'est vraiment "hardcore" comme optimisation!)

[Manu0086]

(amicaux OR coupes OR champ)

Ah oui ça c'est pas bête, j'y avais pas pensé :p

Mettre des INNER JOIN, ok on y verra mieux mais niveau performance ? Je ne pense pas que cela y change grand chose, j'avais déjà effectué des tests.

Oui j'ai bien des index.

Bon je fais l'optimisation à laquelle j'ai pensé, cela ferait déjà appel à une table de moins.

[pcaboche]

Mettre des INNER JOIN, ok on y verra mieux mais niveau performance ? Je ne pense pas que cela y change grand chose, j'avais déjà effectué des tests.

C'est la grande question que je me pose: est-ce que MySQL optimise les jointures en fonction de la cardinalité des tables concernées? (ce qu'on appelle de la "programmation dynamique") Il semble que non (à l'heure actuelle).

Sinon, quelle est la cardinalité (le nombre d'enregistrements) de tes tables?

[Manu0086]

buteurs : 143000
joueurs : 143000
equipes : 9500

Et cela augmente tous les jours...

[pcaboche]

Et bien voilà une optimisation: tu ne fais qu'une seule table "joueurs" dans laquelle tu mets les informations sur les buteurs, cela évitera une GROSSE jointure (je viens de comprendre l'optimisation que tu voulais faire...)

[Manu0086]

ouaip

En posant moi-même la question, j'avais trouvé la solution principale :p

pfff pourquoi quand on développe, on pense pas à tout.... quel temps qu'on perd ensuite :p