Reprise du message précédent :
ben tu l'as très bien expliqué pour les messages dans un topic (je l'ai implémenté aujourd'hui et ça marche même si, comme je l'ai dit, je n'ai pas encore pu vraiment quantifier les effets bénéfiques) mais j'ai pas le souvenir de l'avoir lu pour les topics dans une section du forum.
Mais c'est pas grave, je vais me creuser un peu la tête pour trouver une solution (si je retrouve pas).

pour les topics c'est la même chose

 
Rha mais si même toi tu lis pas ... il n'y aura pas des pages vides

 
Bon alors résumons...
 
- Quand on poste un message dans un topic, on lui donne comme numéro, le nb de messages déjà dans le topic +1.
- Quand on supprime un message dans un topic, on décrémente le numéro de tous les messages suivants dans ce topic.
- Et donc quand on veut récupérer une poignée de messages de ce topic, on prend ceux dont le numéro est "between" les topics qu'on veut afficher.
=> Ca c'est très simple, y'a pas de problème.
 
Maintenant pour les topics dans une section... Si l'on utilise la même méthode...
- Quand on crée un nouveau topic, on lui donne un numéro qui est comme pour les messages le nb de topics dans cette section + 1 (on les affichera en ordre descendant)
- Quand on supprime un topic, on décrémente le numéro d'ordre des topics d'ordre supérieur.
=> Jusqu'ici c'est pareil : un traitement simple fait fréquemment + un traitement potentiellement lourd fait parfois.
SAUF QUE...
Lorsqu'on poste un message dans un topic (traitement très fréquent), il faut réordonner tous les topics d'ordre supérieur en décrémentant leur ordre puis donner le nb de topics comme ordre au topic dans lequel on a posté.
=> Et là, c'est un traitement lourd (surtout si l'on fait remonter des vieux topics ; mais heureusement, c'est plus rare) fait très souvent et je sais pas si on gagne tant que ça par rapport au tri (qui est lui aussi un traitement lourd mais qui ne fait pas d'écriture dans la BD (très lourd))...
Mais bon, je vais vous faire confiance, vous qui avez des BD archi-remplies donc je vais suivre cette solution...

 
C'est pas parce que qui que ce soit dit quelque chose que c'est forcément la vérité vraie, hein
 
Perso je te déconseille, surtout que bon, je vois pas trop comment il peut gerer l'affichage par catégories/sous categories à moins de tenir un compteur séparé
La solution elle est relativement valable sur les topics, mais pas dans les index de cats, enfin c'est mon avis, se tapper un UPDATE de 15 topics à chaque post, ça me parait un peu exageré

Pour les sous cat un champ en plus ouais, bah ça reste toujours plus rapide qu'un LIMIT
 
Ma solution est une solution, je n'ai jamais affirmé que c'était LA solution
 
Donc si vous trouvez mieux, n'hésitez pas à en parler ici

J'attendrai en effet d'autres avis avant de me lancer dans cette "optimisation".
Et puis j'ai encore plein d'autres trucs à faire donc ça n'urge pas.

 
J'ai pas dit le contraire, mais il doit surement y avoir moins lourd  
 

 
C'est xman qui avait l'air de la prendre comme LA solution, pas toi

Ben il disait "Beurk !" avec tant d'assurance...

dis moi Athlon XP, je viens d'installer HFR Enhance 2 et j'ai cette erreur, c'est normal ?
 

Euh, c'est moi ou c'est le point d'exclamation de gnome ca ?

 
Oui, c'est parfaitement normal
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
T'as installé la v1

ah ben oui, bien vu
faites comme si je n'avais rien dit

Tiens, je suis en train de lutter sur mon forum contre un "(:whistle" qui n'est pas interprété dans l'ordre idéal et je constate qu'ici c'est pareil. (même si je crois que je vais laisser couler et on n'aura qu'à mettre un espace avant la " )" si on voulait pas obtenir un "". ( )
 
PS : j'ai bien une solution mais ça implique des trucs qui m'ennuient un peu alors je me tate...

Pour l'interprétation des smilies, j'ai procédé du plus grand au plus petit (je parle du nombre de caractères dans le code du smilie). Ca évite pas mal d'erreurs d'affichage!

je fais ça aussi dans les expressions régulières

C'est ce que je fais pour les codes de smileys qui en contiennent d'autres (genre pour et c'est qui est traité en premier).
Mais ça n'inclue pas ceux qui se chevauchent.

 
Utilise un truc style negative lookahead/lookbehind

Si je dois énumérer dans le lookbehind tous mes codes de smileys se terminant par ":" j'ai pas fini.
Même si j'envisage cette éventualité...
 
En fait, la solution à laquelle je pense est de traiter tout simplement ce smiley en dernier ; mais, dans la liste de smileys, comme c'est un smiley courant, j'aurais envie de l'afficher en premier.
Et si je dois rajouter un champ d'ordre de traitement des smileys différent de l'ordre d'affichage, ça va être chiant pour l'interface de l'admin pour rajouter des smileys...
Enfin bref... Y'a des solutions, faut juste que je trouve la moins chiante à utiliser puis à programmer.
 
EDIT : mais non, je suis con ! C'est déjà ce que je fais pour mes smileys imbriqués (les retrier dans un autre ordre que l'ordre d'affichage). Bref, j'ai rien dit, c'est comme si c'était réglé.

Je veux pas faire mon vilain petit canard, mais le LIMIT, ce n'est peut-être pas la solution optimale, mais c'est une solution viable même si temporaire.
Quand je vois qu'ici j'arrive à la page 376, que ça met 0,691s et que pour aller sur ma page 471 du topic bonjour sur mon forum, je mets 0.386s, bon, voilà quoi.
Je trouve que vous vous prenez beaucoup la tête sur cette histoire de Limit, je sais, personnellement que je traine un poids avec ce limit, mais avant que mon forum ne nécessite de changer de méthode par son nombre grandissant de message, MySQL 6 sera sortie et aura surement optimiser ce genre d'opérations.
 
Enfin, bref, ce que je veux dire, c'est que si vous avez la solution viable, donnez là, mais vous perdez un temps monstre juste pour gagner quelques ms sur les topics à grande page (qui sont relativement rares quand même).
 
Je ne peux pas vous filer les sources de mon forum, par contre, je peux vous donner toutes la méthodologie et toutes mes requêtes SQL au cas par cas, alors si vous avez THE méthode, donnez là qu'on arrête de tourner autour du pot juste pour THE LIMIT.
 
Enfin, vous faites ce que vous voulez, après tout, ça entretiens le topic.

 
Ben non, tu fais un lookahead sur le : blabla : en vérifiant que y'a pas de caractere imprimable derriere

 
Le LIMIT est une solution viable pour les petits forums. Dès que le nombre de messages devient grand, c'est un gouffre en ressources et les temps de requête s'allongent considérablement.

C'est quoi grand ?
Si c'est HFR, combien sur ce topic peuvent prétendre atteindre un tel quota ? Non, parce qu'HFR, c'est ce qu'il y a de plus gros niveau national déjà.
Après, moi avec presque 310000 message, le LIMIT ne me fout pas tout en l'air non plus.
Bien sûr, je n'ai pas 2000 membres simultanée non plus. Mais mon serveur à base de Celeron est ridicule par rapport à HFR.
 
Mais il serait temps de penser aux vrais "nouveautés" d'un forum sur ce topic. Quand je vois que ma proposition de multivote s'est soldé en une page juste pour m'entendre dire que ce n'était pas terrible alors que ça fait un carton chez les utilisateurs. Je trouve dommage qu'on passe vite fait sur les trucs sympas et qu'on se prenne la tête 50 pages pour diviser le temps de génération du LIMIT.

la nuit vers 2h du matin quand ya plus grand monde (quand meme 700 visiteurs ) le topic fait dans les 0.050

non mais arreter de dire n'importe quoi !
 
le limit c'est fait pour cherche un certain nombre de ligne, plus vous cherchez de lignes, plus c'est long.
 
du genre select * from message limit 0,30 ca va etre trés vite s'il l'index est bien placé, par contre limit 500000,30 ca va etre trés long car cette fois ci tu parcourt 500 000 lignes.
 
Faut juste que tu te debrouille pour ne pas parcourir ces 500 000 lignes.

Hum, je peux me planter, mais il me semble que le LIMIT écarte les enregs déjà récupérés par le select... Si tu as 500000 messages dans ton topic et que tu fais

 
Tu vas ramener 500000 lignes pour en afficher ensuite Y à partir de la Xième.

 
Je le suis pas d'accord !
Le LIMIT n'est pas spécialement + lent lorsqu'on veut conserver des lignes éloignées mais parce que s'il est précédé d'un ORDER BY, le tri sera fait sur TOUTES les lignes puis on n'en garde que certaines. Et le tri est long !
Alors que si on se démerde pour utiliser BETWEEN au lieu de LIMIT, on réduit le nombre de lignes à trier.
Et trier 30 lignes, c'est rapide alors qu'en trier 500 000 c'est très long !
 
Exemple d'un topic de 100 000 messages avec LIMIT :

ça va récuperer 100 000 messages, les trier par date puis en renvoyer 30 à partir du 1000ème.
 
Tandis qu'avec BETWEEN :

ça va récupérer 30 messages et ne trier que ces 30-là (et encore je ne suis pas sûr du tout que le tri est nécessaire mais c'est au cas où...)

Euh non, je ne pense pas que tu les ramènes.
Je viens de regarder sur mon forum, la consommation mémoire est identique entre la page 1 et la page 473 du topic "bonjour".

Perso, j'ai un double index sur la colonne idtopic,time, c'est peut-être pour ça que je ne perds pas grand chose avec mes limits. Enfin, je ne perds pas grand chose, je double disons mon temps de gen à la page 473.

Comprends bien le problème ce sont les gros topics plus que le nombre de messages général qui posent un problème avec le limit.

 
J'ai fait un EXPLAIN sur une requete de ce style, qui confirme ce que je pensais...
 

 
Le LIMIT ramène bien la totalité des lignes avant de filtrer... Je précise qu'il y'a une clé primaire sur le champ "idrep"

Je pensais que quand tu disais "ramène", tu parlais de ramener les infos dans le script PHP.

Du tout, et c'est justement là qu'est le gros hic avec le LIMIT pour les topics ou salons volumineux! M'enfin, dans un sens t'as raison, pourquoi se casser la tête si c'est pas nécessaire. Moi j'y ai bien été obligé, et c'est pas plus mal comme ça... L'ensemble de mon forum a été revu et corrigé pour tenir des charges bien plus élevées que celles qu'il supportait à l'origine et comme on dit, qui peut le plus peut le moins!

c'est pas l'order by qui prend du temps, c'est le fait de devoir scanner les x premier avant de trouver le 100000 messages. (parce que si t'as un index sur (topic,date), mysql renvoie les resultats de façon ordonnés de toute façon)

J'ai déjà un index sur topic mais tu veux dire que si je rajoute un index sur date, je peux me dispenser du ORDER BY date, ils seront toujours dans le bon ordre avec ou sans "ORDER BY date" ?
Je savais pas ça. (Han ! Le n0ob que je suis ! )
 
(enfin bon, maintenant que j'ai implémenté la version avec champ ordre, je vais pas revenir en arrière)
 
PS : je suppose (j'espère !) que MySQL le sait et que si je lui dis quand même de faire un "ORDER BY date" il va se dire que c'est pas la peine et ne passera pas du temps à faire un truc inutile, hein ?

Non tu ne peux pas t'en passer, Joce veut dire que c'est "gratuit" je suppose.

Je vais encore poser une question de noob...
 
Qu'est-ce qui est le mieux entre une jointure et une requête dans une boucle ?
Genre, pour lister les messages en affichant des infos sur l'auteur :
 
1°) (avec jointure)
requête messages+auteur
 
2°) (avec boucle)
requête messages
while (message) requête auteur
 
Intuitivement, je dirais que c'est la version avec jointure qui est la mieux car on ne hache pas les accès à la BD et puis surtout SQL doit sûrement arriver à ne pas relire X fois les infos d'un même auteur qui aurait posté plusieurs messages dans la page... Mais j'en suis pas sûr et dans le cas d'une boucle, ça permet de ne pas chercher à lire les infos sur l'auteur dans le cas où il aurait été supprimé (banni).

non, je dis juste qu'avec un index sur (topic,date), mysql aura pas besoin de faire de filesorting si tu lui mets un order by date. (attention je dis pas de rajouter un index sur date, je dis de mettre un compound index sur (topic,date))

Il faut bencher

C'est ce que je fais.    
 
Et ça accélère mon LIMIT...  

m'enfin bon, vaut mieux faire un order sur l'id du message que sur la date du message (avec l'id autoincrement)