index forums

Bonjour,

C'était il y a un certain temps,et un administrateur de l'association hébergeuse
apinc signalait un probleme de reuqete lente avec spip
et une amélioration.

ESJ se déclarait intéressé.

Actuellement, le probleme est à nouveau évoqué,
et il me semble dans la 192
que la solution proposée n'a pas été intégrée
(mais peut être autre chose, mieux ?)

J'aimerais informer apinc de ce qu'il en est.

Rappel des écrits :

> Encore des requetes lentes ce soir, dont pas mal de spip. Cette fois
> j'ai pris la peine de noter ce qui se passait, à faire passer aux
> développeurs de SPIP:
> 
> Les gros soucis semblent être dans les "forums", avec des requetes de ce
> type:
> 
> SELECT forums.* FROM spip_forum AS forums WHERE (forums.id_article =
> '7') AND forums.id_parent =0 AND forums.statut = 'publie' ORDER BY
> forums.date_heure DESC
> 
> Il n'y a pas d'index dédié pour cette requète, et pas de LIMIT dessus.
> Conclusion, ca force le serveur à scanner toute la table dans tous les
> sens pour trier ce qu'il veut et faire son order.
> 
> Si vous avez un spip, vous pouvez tenter ca sur la table forums:
> 
> ADD INDEX `idx_test_admins_apinc` ( `id_article` , `id_parent` ,
> `statut` , `date_heure` )
> 
> L'explication de la requete ci-dessus avant/apres l'index:
> 1 SIMPLE forums ref id_parent,id_article,statut id_article
> 8 const 7895 Using where; Using filesort
> 
> 1 SIMPLE forums ref
> id_parent,id_article,statut,idx_test_admins_apinc
> idx_test_admins_apinc 24 const,const,const 1179 Using where
> 
> Même si il manque toujours un LIMIT a la requete, elle scanne 7 fois
> moins de lignes en utilisant un seul index.
> 
> Evidemment l'index consomme en mémoire, mais c'est beaucoup moins
> grave... Par ailleurs ca peut etre compensé en enlevant d'autres indexes
> sur la table qui ne servent pas après l'ajout de celui la, mais pour ca
> il faut connaitre les requetes de SPIP donc je me garderais bien d'y
> toucher.
> 
> Il ya eu d'autres problèmes liés aux tables "forum_cache", mais je n'ai
> pas eu le temps de m'amuser à étudier ca de plus près.
> 
> -- 
> mat

Réponse de ESJ :

  > Très intéressant. Il y a actuellement l'index "status, date_heure"
 > qui donc n'a pas l'air pertinent, et pourrait etre remplacé par celui-
 > ci, ou par sa
 > généralisation: id_article, id_breve, id_rubrique,
 > id_syndic,id_parent,staut,date_heure. Car il y a déjà qqch qui cloche
 > dans cette table, c'est que les 4 entrées id_article, id_breve,
 > id_rubrique et id_syndic sont telles qu'à toutes les lignes une
 > seules des quatre est non nulle, et SQL n'est pas au courant. Faire 4
 > tables aurait sans doute été mieux, il faut voir si on peut rattraper
 > ça.
 >
 > Merci d'avoir fait suivre.
 >
 > Committo,Ergo:Sum

url du thread historique :
http://forum.apinc.org/index.php?t=msg&th=113084&goto=114937#msg_114937
(il y avait eu xpost sur la liste spipdev je crois aussi)

thread actuel :
http://forum.apinc.org/index.php?t=msg&th=121682&start=40

merci pour tout/s !
JLuc