comment faire dans un forum pour gerer 20 000 sujets sans que ca rame ?
 
y a un "truc" avec les index, mais je ne sais pas comment ca marche...
 
 
HELP
 
http://gigigan.homeip.net/jjndforu [...] =suj&cat=1
0.4 s
http://gigigan.homeip.net/jjndforu [...] =1&suj=134
1.2 s

si c'est bien codé, tu dois avoir autant de requete que tu aie 1 ou 20 000 sujets

c'est le cas, je crois que c'est plus une question d'index et autre sous mysql

yup ?

 
Ben ca y a une requete pour afficher les topics ...
Si c 1 ou 1 000 000 d'enregistrements, je vois pas pk y aurait plusieurs requetes  

Sans source c'est dûr...

dsl de polluer le topic mais sous mozilla ça ne lmarche pas très bien ton code javascript
 
edit : un peu comme ici mais en pire

CorranHorn a écrit a écrit : dsl de polluer le topic mais sous mozilla ça ne lmarche pas très bien ton code javascript   edit : un peu comme ici mais en pire

si si le sujet a juste ete deleté => rien apparait niveau messages mais le top et le bottom si
 
c est bien ca ?

ben tu crées des index sur les champs qui font souvent l'objet de recherches

meme come ca ca rame encore
 
comme ce forum fait pour rester dans ces temps la avec tant de messages ?

J-'-R a écrit a écrit :   meme come ca ca rame encore   comme ce forum fait pour rester dans ces temps la avec tant de messages ?

Moi j'ai 0.0042 pour le premier lien.

Que donne un EXPLAIN sur la requête qui liste tes sujets ?

Et avec seulement 34 enregistrements parcourus ca rame
 
Je suppose que tu as un LIMIT quelque part dans ta requête. Tu as constaté des temps de génération élevé pour un LIMIT 0,35 ? Ou juste pour un LIMIT x, 35, où x représente l'une des dernières pages de ton forum ?

j'ai fait un dellete, au debut un il y avait 20 024 enregistrments, et la ca ramais...
 
j ai un limit mais ca rame pour toutes les pages pareilles

Difficile de te venir en aide sans plus de précisions.
 
Avec la structure de la table et la requête MySQL ce serait beaucoup plus simple. A moins que tu ne veuilles garder tes sources confidentielles ?

 
j'ai remplacé les var de la requetes par leur premieres valeur ( page 1 )
 
si tu peux toujours m aider

je sais bien qu il y a un dateheure et un date et un heure
mis le date et le heure sont sensé bientot disparaitre au profil du dateheure ( on m a conseillé ca )

Déjà, il y a un gros soucis avec ta requête. En utilisant un ORDER BY DESC, les index ne te sont d'aucune utilité. Une solution pourrait consister à stocker la date de tes messages sous forme de TIMESTAMP inversé (0-TIMESTAMP) afin de faire un ORDER BY ASC. C'est pas super élégant, mais ca marche ...
 
Parce qu'en l'état actuel des choses, si tu as 20.000 sujets dans ta table, c'est 20.000 enregistrements qui sont parcourus à chaque requête, même si c'est pour n'en retourner que 20. Inutile de dire que le classement par date, puis par heure ne fait qu'empirer les choses, mais bon, ca tu vas le corriger

Autre chose : tu devrais optimiser le type de tes champs. L'impact sur les performances n'est pas énorme, mais c'est toujours ca de prit Commence par remplacer les champs mediumint(9) par des mediumint(8) de type UNSIGNED.
 
Le champ ferme se contentera à merveille d'un tinyint(1). Autre chose : tu gagneras en perfs en dissociant tout ce qui concerne les sondages dans une autre table. Laisse juste un champ sondage de type tinyint(1) qui prendra les valeurs 0 ou 1. C'est d'autant plus vrai que tu stockes visiblement la liste des votants dans un champ de type text. Il serait plus intéressant de créer une nouvele table composée de 3 champ (une clefprimaire, une clef s_id et une clef membre_id).

Es-tu sûr de ce que tu dis ? Parce que là ça m'intrigue. Dans le post au dessus je vois que c'est seulement quand il y a des champs pouvant être NULL que ce n'est pas utilisé, or les champs de J'R sont NOT NULL.

 
Ou lorsque l'index s'applique sur plus de 30% des enregistrements

tes key sur date et heure -> un seul message par jour et un seul message par heure !!
 
 
fait gaffe a tes clefs !!
CA CHIE !

si qq1 a l equivalent de nexen.net pour mysql ( sachant que nexen le fait mais ca marche pas chez moi )

 
Les clés sont bonnes. Pas forcement utiles, mais bonnes!!! Elles n'ont pas de contrainte d'unicité. Les doublons sont donc acceptés.
 
Sinon pour ce qui est de l'order by, celui-ci n'affecte pas les index, puisqu'il n'est traité qu'apres selection des enregistrements conformes à la clause WHERE. Le tri s'effectue sur le resultat, mais necessite de créer une table de travail, ce qui augmente enormement le temps de traitement.