Reprise du message précédent :
J'ai expliqué comment résoudre le pb

je suis pas sûr que ça règle le problème de 3 pages manquantes sur 15000 (loin de 10%) mais de toutes façons, même si ça prend quelques secondes, comme on ne supprime pas souvent des messages, autant ne pas se faire chier et faire le traitement et pas compliquer les choses.

c'est pas 10% du total, c'est lors de l'affichage d'une page, si il manque plus de 10% (chiffre exemple hein) de posts sur le nombre de post escompté dans la page (genre si y'a que 26 posts au lieu de 30) alors la on lance la requète d'étalement du manque, et la page refait 30 posts, mais y'a 4 pages parmis les 50 suivantes qui n'ont que 29 posts.
 
En fait l'algo peut marcher aussi avec une "tolérance zero" et on voit tout le temps 30 posts

mieux vaut passer 5 secondes à renuméroter à un moment où avec un peu de chances, personne ne cherchera à lire sur le forum plutôt que de faire attendre 5 secondes le 1er gus qui veut lire la page fatale.

Il attendra pas 5 secondes, en cas de hit sur une page creuse, je ne renumérote pas tout mais quelques pages suivantes seulement (en gros je fais le boulot petit à petit à la demande).

0x90 => Ton exemple, c'est de la théorie ou tu l'appliques vraiment ?

Je comprends pas votre logique.  
 
Certes, ca va faire une charge supplémentaire au serveur d'updater des messages. Mais il y a tellement peu de personnes qui suppriment leurs messages et qui plus est au début d'un topic de 500000 pages c'est encore moins probable.
 
Mais imaginez tout de meme qu'a chaque lecture on ne calcule pas le nombre de pages. et leurs positions. On économise des ressources serveur énormes!
 
Et puis vous savez, si vraiment c'etait embetant, au lieu de supprimer le message, on peut tout simplement remplacer le message par MESSAGE SUPPRIME. Ca garde la position, mais ca enleve le contenu du post.

Cette solution revient au même que de masquer un message s'il est supprimé. Si il y a beaucoup de delete (pour les pages "importantes" des topics), ca risque de te faire des pages pleines de "message Supprimé"

Et puis bien sur c'est rare les delete au début d'un topic de 500 000 posts mais ca arrive pour le cas que je viens de t'énoncer + haut... Donc voilà quoi  

EDIT : HS : A partir de quelle version de MySQL on peut faire des requetes imbriquées?

4.1 ?

Ah, tant mieux    je pensais que c'était 5.0 et dans ce cas ça m'aurait géné pour la portabilité de mon forum...

Si c'est 4.1 ca devrait aller...

Starting with MySQL 4.1, all subquery forms and operations that the SQL standard requires are supported, as well as a few features that are MySQL-specific.
http://dev.mysql.com/doc/refman/4.1/en/subqueries.html

 
Non c'est de la théorie, j'ai pas de forum à moi j'ai pas encore trouvé le temps de me lancer.
Cela dit je doute que je l'utilise vraiment, c'etait juste une idée qui me passait par la tête
 
 

sauf que si tu fais un mass delete, t'auras des pages vides

Quelle est la façon la plus efficace de connaître le nombre de lignes dans une table ?
Je pense notamment au nombre de topics et au nombre de messages dans un topic car pour découper en plusieurs pages, il faut savoir combien il y en a ce qui m'oblige pour l'instant à faire au moins 2 reqûetes à chaque fois : d'abord savoir combien il y en a puis de récupérer ceux qu'il faut afficher dans la page en cours.
 
Vaut-il mieux faire 1°) comme ça ? (récupérer toutes les lignes puis les compter)

 
2°) Comme ça ? (les faire compter par MySQL)

 
Ou bien, 3°) dans le cas des messages, rajouter un champ nbmessages dans la table `topics` et le mettre à jour à chaque ajout/suppression de message ? (j'ai dans l'idée que c'est cette dernière solution qu'il faut retenir mais j'aimerais vos avis)
 
Ou bien y a-t-il encore une meilleure solution ?

La seconde est beaucoup plus efficace car stockée directement dans la table (de plus elle ne renverra pas inutilement des valeurs)
 
pour le nombre de réponses dans un topic je le stocke dans un champ en ce qui me concerne, ça évite de faire des couts dans les requêtes de sélection.

Bref, l'ordre d'efficacité (du meilleur au pire) est 3 2 1 quoi.
C'est ce que je présupposais...

uniquement pour MyISAM, pas pour InnoDb

Ca tombe bien, mes tables sont de ce type.

 
Tu veux dire que la première propal serait plus efficace pour InnoDB
 
J'ai un peu tendance à douter quand même, on pourrait avoir des tests

Qui utilise InnoDb ici ^^ ?

 
SQL_CALC_FOUND_ROWS
 
Bcp bcp bcp moins gourmand

ça c'est bon quand t'as besoin de calculer le nombre de lignes de la requête, en gros quand tu fais une requête quoi, si tu veux juste connaître le nombre d'enregistrements d'une table (sans autre requête donc) le COUNT sera largement moins gourmand puisque stocké dans la table.

Bah a priori, c'est pour compter le nombre de messages dans un topic, donc il a déjà sa requête pour récupérer les messages

Houlà, ça m'intéresse ça.
C'est mieux qu'un mysql_num_rows ?

moi pour la table "online"

Table des utilisateurs en ligne? Pourquoi ne pas utiliser une table "MEMORY"?

ha non je confond, c'est une "heap" .  

Comme le disait Anthomicro, le SQL_CALC_FOUND_ROWS te retourne le nombre de lignes de ta requête.
 
Comme ceci :
 
SELECT SQL_CALC_FOUND_ROWS * FROM table_messages WHERE topic = 1 LIMIT 0,10;
SELECT FOUND_ROWS();
 
Le FOUND_ROWS() ne prendra alors pas en compte la clause LIMIT et te retournera le nombre de messages total du topic N°1

Pour peu que la personne utilise le LIMIT pour recuperer une page de messages

Ce qui n'est pas efficace, on en revient donc au point d'avant ^^
 
Sinon ouais autant utiliser HEAP pour les connectés, pas besoin d'avoir une sauvegarde du contenu de cette table en cas de reboot du PC

Je dis juste qu'avec innodb les count(*) ne sont pas optimisés. Faut maintenir un compteur à part.

Vaut mieux ne pas utiliser de LIMIT pour récup les messages mais pour récup les topics, ça fait toujours besoin, non ?
 
Donc pour récupérer les topics d'une section (forum ou sous-forum) qu'on veut afficher tout en connaissant le nombre total de topics de cette section (pour afficher les liens vers les autres pages), faudrait faire un truc du genre ?

 
Y'a-t-il encore plus simple que la dernière ligne lorsqu'on sait qu'une requête renvoie une seule ligne avec une seule valeur entière ?

Beurk, c'est lent

C'est bcp plus léger niveau ressource

Faudra que je teste mon forum en local un jour car là j'ai passé mon après-midi à optimiser des trucs et je n'ai pas vu d'amélioration chiffrée.
C'est toujours autour de 0.5 secondes (que ce soit pour lister les topics ou les messages d'un topic) chez Free.
Mais si ça se trouve, il y a de plus en plus de charge en soirée et donc il y a une réelle amélioration...
J'ai quand même vu des descentes à 0.2 secondes

Sa solution ? avec le LIMIT ? c'est affreux ^^
 
Je parle pas du SQL_CALC_FOUNDROWS, mais du LIMIT...

Je ne demande qu'à l'améliorer.
Mais pour des topics qui changent sans cesse d'ordre (contrairement à des messages dans un topic qui gardent toujours le même ordre) j'ai du mal à voir comment faire sans LIMIT.

Hmm, cherche pas, si tu veux vmt chiffrer tes perfs, oublie les serveurs FREE Essaye de prendre une petite formule à quelques euros/an pour prendre un hébergement mutualisé
 

Ha, autant pour moi

 
C'est justement un des gros sujets de débat dans ce topic... Je crois que les personnes ayant trouvé une solution performante préfèrent garder pour eux leurs astuces, et c'est bien compréhensible! Il y'a quand même quelques piste à suivre et des choses à éviter qui ont été apportées, c'est un bon début!

Bah j'ai quand même détaillé comment je faisais avec le BETWEEN, je vais pas filer le code non plus lol ^^
 
On en a débattu pas mal dans les dernières pages... faudrait relire les dix dernières pages tu devrais trouver

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).