Discussion :

[sawati]

Bonjour je me suis fais taper sur les doigts par mon hébergeur parce qu'une de mes requête est trop lourde en terme de ressources sur leur serveur MySql.

Donc j'aimerais optimiser cette requête mais elle est trop avancé pour mon niveau en sql...

Code :

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

1
2
3
4
5
6
7
8
9
10
SELECT P1.topic_id, T.tid, T.title, T.posts, T.forum_id, F.name, F.id, P1.pid
			FROM ibf_topics T INNER JOIN ibf_forums F ON T.forum_id = F.id
							  INNER JOIN ibf_posts P1 ON P1.topic_id = T.tid
							  INNER JOIN ibf_posts P2 ON P2.topic_id = T.tid     
			WHERE    T.forum_id != "22"
				 AND T.forum_id != "28"
				 AND T.forum_id != "36"
			GROUP BY T.tid, P1.pid
			HAVING P1.pid=MAX(P2.pid)
			ORDER BY P1.pid DESC LIMIT 12

l

C'est une requête pour afficher les derniers topics où ont été posté les derniers posts ainsi que le forum auquel ils appartiennent. les forum 22, 28 et 36 sont destinés aux administrateurs et modos. Voilà tout est dit.

Merci.

[PS : Il s'agit d'un forum IPB]

[qi130]

Est-ce que

Code :

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

WHERE    T.forum_id not IN ( "22","28", "36")

améliore les perfs ?

[sawati]

A mon avis c'est plus dans la recherche des derniers topics qu'il faut chercher, c'est ce qui doit consommer le plus.

[Sivrît]

La question de routine: Quels sont les indexes définis ?
On pourrait avoir un explain ?

Dans tous les cas c'est une requête plutôt moche (ce n'est pas vraiment un reproche car il n'y a guère d'alternatives) qui va mal réagir à l'augmentation de taille de la base.

Si la version de mysql le permet, il serait peut-être possible d'utiliser une sous-requête pour récupérer le max des pid (avec un index sur (topic_id, pid)), ce devrait être moins pire.

L'idéal (pas le plus pratique mais qui règle les perfs de cette requête), est de garder pour chaque topic la référence du dernier post. C'est rapide à mettre à jour lors de l'ajout des messages (éventuellement via un trigger pour ne pas oublier), et ça remplace le join²/group/having qui fait mal par une simple jointure.

[sawati]

Pour ibf_forums :

Nom de la clé Type Cardinalité Champ
PRIMARY PRIMARY 36 id

position INDEX 36 position
parent_id

Pour ibf_topics :

Nom de la clé Type Cardinalité Champ

PRIMARY PRIMARY 1415 tid

topic_firstpost INDEX 1415 topic_firstpost

forum_id INDEX 35 forum_id
pinned
approved

last_post INDEX 1415 forum_id
pinned
last_post

starter_id INDEX 707 starter_id
forum_id
approved

title FULLTEXT 1 title


Pour ibf_posts :

Nom de la clé Type Cardinalité Champ
PRIMARY PRIMARY 12924 pid

author_id INDEX 6462 author_id
topic_id

post_date INDEX 12924 post_date

topic_id INDEX 12924 topic_id
queued
pid
post_date

post_key INDEX 6462 post_key

ip_address INDEX 4308 ip_address

post FULLTEXT 1 post



Voilà les index, désolé pour la mise en forme ...

[sawati]

La question de routine: Quels sont les indexes définis ?
On pourrait avoir un explain ?

Dans tous les cas c'est une requête plutôt moche (ce n'est pas vraiment un reproche car il n'y a guère d'alternatives) qui va mal réagir à l'augmentation de taille de la base.

Si la version de mysql le permet, il serait peut-être possible d'utiliser une sous-requête pour récupérer le max des pid (avec un index sur (topic_id, pid)), ce devrait être moins pire.

L'idéal (pas le plus pratique mais qui règle les perfs de cette requête), est de garder pour chaque topic la référence du dernier post. C'est rapide à mettre à jour lors de l'ajout des messages (éventuellement via un trigger pour ne pas oublier), et ça remplace le join²/group/having qui fait mal par une simple jointure.

Arriverais-tu à me faire les modifications dont tu parles s'il te plaît ?