Discussion :

[T-nia]

Bonjour,
je rencontre des problèmes de ralentissements avec mes requêtes et je ne comprend pas vraiment pourquoi, voici ma requête: (j'obtiens une liste de news à afficher).

Code :

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

1
2
3
4
5
SELECT n.*, u.email, u.login, c.categorie_name AS categorie 
FROM news n 
INNER JOIN user u ON u.id_user = n.id_user 
INNER JOIN news_categorie c ON c.id_news_categorie = n.id_category 
ORDER BY n.id_news DESC LIMIT 0,20

Durée d'exécution : 0.4515s. (en moyenne), pendant que certaines requêtes plus petites s'exécutent en 0.0004s. à côté.
Du coup je passe de 0.0096s. à 0.4611s. de chargement :/

J'ai essayé de comprendre pourquoi et apparemment il se pourrait que ce soit aussi dû à un problème d'index dans mes tables, mais comme là dedans je n'y comprends rien, j'ai du mal à faire quoi que ce soit

Voilà une capture d'image de mes trois tables concernées, si ça peut aider :
Table news
Table news_categorie
Table user

Je le rappelle je ne m'y connais pas du tout sur les champs à mettre en index et les clés machins, donc si en plus d'avoir la gentillesse de me répondre vous auriez la gentillesse de faire une réponse assez simple et clair pour moi je vous en remercierai très chaleureusement

Merci d'avance.

[dubble]

salut! est-ce que tu pourrais faire un explain de ta requete pour qu'on voit comment mysql effectue les jointures?

[T-nia]

Oui, voilà ce que ça me dit :

Code :

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

1
2
3
4
5
 
id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra
1 	SIMPLE 		c 	ALL 	id_news 	NULL 	NULL 		NULL 	3 	Using temporary; Using filesort
1 	SIMPLE 		n 	ALL 	NULL 		NULL 	NULL 		NULL 	6 	Using where
1 	SIMPLE 		u 	eq_ref 	PRIMARY 	PRIMARY 4 	bdd.n.id_user 	1

[dubble]

Mysql n'effectue pas les jointures dans le sens ou tu les as mises.Je pense que tu vas avoir soit besoin de créer un index sur la table news pour la colonne id_category, soit indiquer a mysql de respecter le sens de tes jointures en rajoutant la clause straight_join dans ta requete. Le problème vient du fait qu'il y a moins d'enregistrements dans ta table catégorie que dans les deux autres, mysql privilégie donc cette table comme point de départ.

[T-nia]

Je viens d'essayer en ajoutant un STRAIGHT_JOIN mais je n'observe aucune, ou bien très légère, différence.
J'ai aussi rajouter une clé de type index sur mon champ id_category de ma table news mais je n'ai pas vu non plus de réel différence
J'ai peut-être mal fait quelque chose je ne sais pas. Merci de ton aide en tout cas.

[Sivrît]

Est-ce que les tables sont déjà bien remplies ? Sur les captures d'écran elles ont l'air très petites. Ca pourrait influer sur les choix de mysql et les performances (expliquer qu'il y a peu de différence entre les différentes approches).

Sinon utiliser des "LEFT JOIN" pourrait inciter mysql à applique le LIMIT immédiatement (même si en général on tente d'éviter les jointures ouvertes inutiles).

Si la version de mysql le permet peut-être même viser :

Code :

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

1
2
3
4
5
6
7
8
 
SELECT n.*, u.email, u.login, c.categorie_name AS categorie 
FROM (SELECT *
      FROM news
      ORDER BY n.id_news DESC LIMIT 0,20) AS n
INNER JOIN user u ON u.id_user = n.id_user 
INNER JOIN news_categorie c ON c.id_news_categorie = n.id_category
ORDER BY n.id_news

Accessoirement il serait probablement utile (mais pas forcément pour cette requête) d'indexer news.id_user et news.id_category. En général les champs qui font référence à d'autre tables sont de bons candidats pour les indexes.

[T-nia]

J'ai ajouté un index sur tout mes id qui interviennent (primaire pour l'auto-increment) et j'ai essayé ta requête: j'obtiens de bien meilleurs résultats
Ma requête s'effectue le plus rapidement, après plusieurs test, en 0.0105s. (au lieu de 0.4s en moyenne avant).
Cependant la moyenne reste de 0.04s et des poussières, car et je ne comprend pas bien pourquoi ça m'énerve :p, parfois ma requête s'effectue en 0.4531s. (valeur maximum que j'ai pu testé).
Pourquoi c'est pas "presque" tout le temps pareil ? C'est énervant :p
En tout cas déjà merci je gagne 10 fois plus de temps qu'avant à certains chargement. Mais je trouve que c'est encore un peu trop pour le peu de résultats renvoyés :s
Oui mes tables ne sont pas remplies quasiment (6 insertions pour la table news, 4 pour la table user et 3 pour la table categorie).
Merci de ton aide.

Edit: je voulais savoir aussi, est-ce que si d'autres requêtes s'effectuent en même temps sur la page, parfois sur la même table, cela peut influencer le temps de chargement D'UNE requête ? le temps de chargement de la page en entier je le sais bien mais c'est simplement pour savoir si une requête effectué indépendament est aussi rapide qu'une requête effectué avec quelques requêtes supplémentaires ? (environ 5 autres, avec quelques une intervenant sur les tables user et news).

[Sivrît]

J'ai ajouté un index sur tout mes id qui interviennent (primaire pour l'auto-increment) et j'ai essayé ta requête: j'obtiens de bien meilleurs résultats
Ma requête s'effectue le plus rapidement, après plusieurs test, en 0.0105s. (au lieu de 0.4s en moyenne avant).
Cependant la moyenne reste de 0.04s et des poussières, car et je ne comprend pas bien pourquoi ça m'énerve :p, parfois ma requête s'effectue en 0.4531s. (valeur maximum que j'ai pu testé).
Pourquoi c'est pas "presque" tout le temps pareil ? C'est énervant :p
En tout cas déjà merci je gagne 10 fois plus de temps qu'avant à certains chargement. Mais je trouve que c'est encore un peu trop pour le peu de résultats renvoyés :s

Sur une unique requête, tout particulièrement si courte, un rien peut faire changer le temps d'exécution. Il suffit par exemple que l'os ou un autre programme utilise le disque pour entrainer un délai supplémentaire.
En outre une même requête n'est pas toujours réalisée de la même façon. Le choix du plan d'exécution dépend des indexes présents et des statistiques internes du serveur sur les tailles des tables et la sélectivité des indexes. Je n'en suis pas certain mais elles peuvent être mises à jour entre deux exécution d'une requête et changer les choix du serveur (surtout qu'avec si peu de données un rien peut tout changer) .
Il y a aussi les caches qui jouent. La première exécution risque de solliciter le disque alors que les suivantes ont la quasi certitude de passer ne serait-ce que par le cache de l'OS.

Oui mes tables ne sont pas remplies quasiment (6 insertions pour la table news, 4 pour la table user et 3 pour la table categorie).

Mauvais plan. Optimiser ses requêtes sur des données aussi irréelles sera probablement contre productif. Là les données tiennent sans problème en RAM, ça pourrait (suivant la quantité futur et la machine) changer. Le LIMIT ne sert même pas, et pourtant il sera vital de l'appliquer le plus tôt possible dans les cas réel pour limiter les données manipulées par la requête.

Sur si peu d'enregistrements les serveur risque de décider que parcourir la table sera plus rapide de d'utiliser un index (ce qui est tout à fait possible), ou que le LIMIT ne sert à rien. Or ça sera du suicide sur une grosse base, mais le serveur n'aura peut-être pas alors les indexes où une requête qui si prête car tout aura été prévu pour des données plus petites.

Il faudrait vraiment remplir les tables plus substantiellement, ça creusera vraiment l'écart entre ce qui marche (garde un temps plus ou moins constant) et ce qui est lent (avec des temps proportionnels à la taille des tables).

Edit: je voulais savoir aussi, est-ce que si d'autres requêtes s'effectuent en même temps sur la page, parfois sur la même table, cela peut influencer le temps de chargement D'UNE requête ? le temps de chargement de la page en entier je le sais bien mais c'est simplement pour savoir si une requête effectué indépendament est aussi rapide qu'une requête effectué avec quelques requêtes supplémentaires ? (environ 5 autres, avec quelques une intervenant sur les tables user et news).

En règle générale un serveur chargé mettra plus de temps à répondre. Mais ça dépend de la charge et des ressources de la machine. Par exemple des modifications en cours vont retarder la requête alors que si les disques suivent et qu'il y a plusieurs processeurs de simples interrogations sont assez parallélisables.
Je dirais que la mesure la plus importante devrait plutôt être le nombre de requêtes/pages que l'on peut servir (le débit quoi).


Sinon, vu le nom des table je me dis qu'il y aura peut-être peu de modifications de ces trois tables (du moins en comparaison des lectures). Si c'est le cas le "query cache" donnera des temps de réponses ridiculement bas pour la majorité des interrogations.