Reprise du message précédent :
ovni >>> En regardant un peu ton code source, j'ai pu voir que tu trichais pour l'affichage des temps de génération

lol tu es courageux

rainbow_efreet >>> Ben merde alors, tu fais plus dans le multi forum ?

Le COUNT est une merde finie si tu lui ajoutes une clause WHERE
 
J'avais testé un jour sur 80 000 enregistrements, pour n'en compter qu'un seul, la requête s'exécutait en 0.2-0.3s Le FOUND_ROW en 0.0002s

Oui mais pour faire le FOUND_ROW tu dois faire un select avant non ? Donc si seul le count t'interresse (et pas les sélections) tu dois additionner le select+ le found_row pour avoir la même fonctionnalité que le COUNT non ? et d'ailleurs ya pas une fonction qui retourne le nombre de lignes ?

En local ça marche peut-être bien ton truc mais franchement, c'est pas sensé comme méthode

Il parse simplement les enregistrements, mais ne les ressort pas ... Le COUNT parse aussi
 
Sinon mysql_numrows ...

 
PS : J'ai oublié
 
Ca peut-être très utile dans le cas suivant :
Page de listing des topics, tu fais ta requête pour ressortir les enregistrements + le FOUND_ROWS pour savoir combien il y a d'enregistrements ...
 
Si tu fais un mysql_numrows ou un COUNT, tu vas reparser ta table une seconde fois pour rien

un SELECT count(id) FROM `table` est le plus rapide car la requete prendra le resultat directement à partir du nombre d occurence de la clé primaire donc la requete sera ultra rapide.
 
Scull >> Si mon forum est tjrs multiforum d'ou la variable GET 'forum' mais c'est juste que j'ai enlevé l'interface de création de forum en ligne ...

 
Un SELECT COUNT(*) FROM table WHERE machin = 'truc' ne l'est plus

* n'existe pas. Ou plutot ne devrait pas exister.

J'ai dis : SELECT COUNT(id) FROM `table`

Bah j'ai jamais parlé de COUNT(id) depuis le début

Ouai ben t'as posté ça ->
 
$requete = mysql_query("SELECT truc FROM ta_table" );  
$exec_requete = mysql_query("SELECT FOUND_ROWS()" );  
$total=mysql_result($exec_requete,0);  
 
et je te dis que ça ->
 
SELECT COUNT(id) FROM `table`
 
C'est mieux c'est tout

 
 
Effectivement, j'aurai du mettre :
$requete = mysql_query("SELECT truc FROM ta_table WHERE truc = 'bidule'" );  
$exec_requete = mysql_query("SELECT FOUND_ROWS()" );  
$total=mysql_result($exec_requete,0);

A quel moment dans ton script de forum tu as besoin de faire un count avec clause where ?

Sur la page de listing des topics

Tu ne tiens pas de compteur ?
Ou c'est pour trouver a quelle page se trouve un message particulier pr rediriger le mec a la bonne page apres une edition par exemple ?

Au début j'avais un compteur en dur ds ma table ... Mais ce n'est plus possible quand tu gères les "Sujets participés" et les "Sujets Consultés" ... Donc je dois retourner dynamiquement les résultats pour chaque membre

Pourtant je l'utilise pour le mien. J'ai un compteur. Je ne fais jamais de count en lecture.

Et cmt tu fais pour récupérer le nombre de topics qu'un membre a uniquement consulté, dans une catégorie précise ?

pkoi recuperer le nombre? Je ne vois pas l'interet de la chose.

Pour calculer le nombre de pages

A la sauce HFR? Dans ce cas oui, je serais obligé de le calculer. Pour le moment, je ne le fais pas. Je n'aime pas ce mode d'affichage.

Comme ici effectivement

je vois pas trop comment se dermerder, à moins de tenir un compteur lu/participé pour chaque user/cat/ss-cat. Ce serait bien lourd. Etant donné la faible quantité de drapeaux et l'efficacité de l'index que l'on peut placer, le count est tres peu consommateur.

Ca reste a voir ... Si t'as une table avec 1 000 000 de drapeaux, et que tu dois en piocher ne serait-ce qu'une centaine dedans, ton COUNT va ramer avec ta clause WHERE

et pourquoi. C'est le principe d'un index bien placé.

Tested and Disaproved Apparement, les index sont très mal gérés ...

il faut forcer les index avec USE INDEX et ça ameliore des fois

Aussi tested mais tjs perfs médiocres

bon, je viens de tester avec une table de 9655 records et j'ai lancé une centaine de fois 2 requêtes dessus (visant exactement 200 records):
 
La première occurence:

 
La dernière:

 
J'ai regardé mon listing en diagonale, les résultats intermédiaires sont dans les mêmes proportions.
 
Max> l'index est sans doute mal géré, mais à mon avis, le problème vient de toi
 
edit: le SQL_NO_CACHE, c'est pour éviter de fausser les résultats.

moi je vous propose de tout passer en handler.

Bon, vous m'embrouiller.
 
Je crois que je vais garder mon habitude du mysql_num_rows pour le moment.
Je m'inquiéterais si les perfs de mon forum deviennent catastrophique un jour.

A gauche, ce sont les temps en secondes ?
Si oui, c'est tout bonnement énorme
 
Teste le FOUND_ROWS
 
Cinocks > Le HANDLER ca va si tu cherches une ligne, pas plus

tu ne peux pas naviguer dans les resultats avec ?

Bah niveau performance, ca arrache si tu cherches une ligne, sinon ça devient très bof

mouarf pas dit que tu y gagnes

Comme tu veux, mais l'info est là

Non hein, c'est en millisecondes, quand même

0.98 ms
T'as fais ton bench avec quel prog ? Parce que normalement, une simple ouverture de BDD prend déjà 1-2-3 ms

Ah mais je compte pas l'ouverture de la DB hein, c'est le temps d'exécution de la requête seule
 
C'est un script PHP

Oki doki
 
Essayes quand même le FOUND_ROWS ^^