Reprise du message précédent :

Pourquoi tu as besoin de ca alors qu'en page index tu affiches le nombre de sujets dans chaque forum?

Je répète, je m'en sers pour calculer le nombre de pages quand tu listes les flags dans une catégorie

k je me disais

 
Sur oui, prends la premiere requete seule et calcule. Tu verras son temps d'execution, singulierement proche d'un count.
 
Sinon gagner 0.5s, c'est enorme tout de meme. Il n'y pas un autre pb de conception?

Ici j'ai un index composé de deux champs dont fldtopcaidn:
 

 
Second essai avec un index sur le seul champ fldtopcaidn:
 

 
Ici, je traitais 120.000 enregistrements sur un total de 1.091.813, et cet ensemble de requêtes a été lancé 100x.

C'est même certain.

Chelou
 
Le COUNT(*) seul est plus performant donc
 
Autre test :
Essayes de chopper un champ genre :
 
SELECT SQL_NO_CACHE COUNT(*) as total, un_autre_champ FROM tblmesg_20 WHERE fldtopcaidn=1 GROUP BY je_sais_pas_quoi;
 
Ptete qu'en définitive, le FOUND_ROWS est plus performant sur ce genre de requêtes
 
Pourtant, je mettrais ma main à couper que chez moi ça a grave boosté les choses (Benchs à l'appui à l'époque, j'ai pas déliré )

C'est évident que le COUNT(*) est plus rapide qu'aller chercher les enregistrement et puis regarder combien de résultats on avait.

C'est ce que je me tue à lui dire
 
Ya quand même une sacrée différence pour MySQL à recueillir UNE info avec un COUNT, plutôt que 200000* le nombre de champs (et il faut encore balancer l'info à PHP pour qu'il la traite)
 
Ya absolument rien de bizarre là-dedans

C'est pas si évident que ça non
Ton COUNT parse entièrement la table aussi

C'est comme un SELECT truc FROM table WHERE champ=1 RODER BY id ASC LIMIT 0,10.
 
Si ta table fait 1 000 000 d'enregistrements, ta requête mettra plus de deux secondes à s'effectuer
 
C'est pas si évident que ça non plus vu qu'il ne récupère que 10 enregistrements

Donc rien n'est évident avec MySQL

Il y a une différence entre parser une table et extraire l'info d'une table. Recompte voir combien tu ramènes d'informations quand tu fais ta requête
 
Un COUNT, ça ramène UN row dans UN champ calculé. Toi tu en ramènes 200.000 multiplié par le nombre de champs. C'est énorme comme différence. Et tout cela doit être traité par MySQL, par PHP, ce qui suppose que l'information en question transite entre les deux logiciels.
 
Je ne vois pas comment faire plus clair

Erreur, formulée comme ça, la requête va parser les 10 premiers enregistrements qui correspondent à la condition champ=1. Il s'arrêtera ensuite parce que le LIMIT est présent.

T'es sûr de rapporter les 200 000 enregistrements ? Avec un mysql_fetch_array oui, mais sans ?

Erreur Il va te trier TOUTE la table par champ=1 puis id ASC, et ensuite te sortir 10 enregistrements
 
Quand je te dis que rien n'est évident
 
Mais bon, t'as raison sur le COUNT

s'il est placé sur un index, il ne parse que l'index, et surtout ne stocke pas de pages resultat. Ca prend moins de place et demande forcement moins de travail.

Erreur encore une fois (mais bon j'admets la mienne )
 
il trie sur id, puis il prend les 10 premiers qu'il trouve

 
euh, tant que tu ne demandes pas explicitement à y accéder l'info ne transite nulle part hein

ben l'info est retournée par le COUNT, je ne vois vraiment pas le problème
edit: oui je vois ce que tu veux dire mais vu qu'il la demande, MySQL doit bien l'entreposer quelque part et ça bouffe de la ressource

 
Tout à fait ce doit etre stocké coté MySQL en Memoire. Ca consomme de la ressource.

Bah justement ^^ S'il trouve 999 999 enregistrements (champ=1) et qu'il te les trie, tu tues ton serveur sur place
C'est seulement après avoir trié les 999 999 enregistrements qu'il va te prendre les 10 premiers

Et c'est ce que tu fais avec ta requête

Vi vi, c'était juste pour donner un exemple pas évident du tout
 
A l'époque j'avais posé moultes questions à ce propos sur de nombreux forums (HFR, DVPEZ.COM, PHPFRANCE, etc), et personne n'a été foutu de me répondre
 
C'est d'ailleurs pour ça que, sans tips, si un sujet de forum compte genre 250 000 réponses, je ne te raconte pas comment tu mets le serveur à genoux si tu fais un ORDER BY + LIMIT

 
PAs de raison de faire un order by pour des messages, puisqu'ils arrivent les uns derrieres les autres. Et le limit est à eviter sur du gros volume.

Heu Suffit que tu supprimes un message au milieu, et lors du prochain post inséré, il sera inséré physiquement dans le trou ... Et là, adieu la continuité de tes messages

Euh, j'vois pas le rapport. Les messages restent ordonnés. Meme s'ils ne le sont pas physiquement, ils le sont logiquement.

Pas du tout
 
Si tu as des messages :
 
ID 1
ID 2
ID 3
ID 4
 
Tu fais un SELECT * FROM table WHERE id_topic = 1 par exemple, ca te ressortira : ID1 > ID2 > ID3 > ID4
 
Maintenant, si tu supprimes ID3, et que tu rajoutes un nouveau message, tu auras :
 
ID 1
ID 2
ID 5
ID 4
 
Et là, bye bye la continuité de tes ID D'où la nécessité du ORDER BY ID ASC

bah oui, mais ton index sera dans ta clé primaire je l'espere, auquel cas, tes enregistrements seront dans l'ordre. Sans index, je suis daccord sur ton raisonnement

L'index réagit de la même facon C'est juste que c'est un fichier physique indépendant (Bien qu'ayant des liens avec les autres ) ... Donc normalement, si t'as un trou dans ton index, c'est pareil
 
Ceci dit, un ALTER TABLE règle ce problème, mais sur des grosses tables, ce n'est pas gérable toutes les 30s

Non, en MySQL, la clé primaire n'intervient pas si tu fais un SELECT sans spécifier d'ORDER BY. MySQL sort les champs strictement dans l'ordre où ils se trouvent dans le fichier.

 
Non MySQL comme tout moteur utilise le B-tree pour ses index (le plus souvent). Le fonctionnement meme d'un B-tree interdit les données de l'index desordonné. Donc si le champ figure dans l'index tu ne pourras pas avec 1,2,5,4. Fais le meme essai avec un index, ce sera suffisant comme preuve.

Ma biche, ca roxxe, on est d'accord ?

Hum, t'as ptete raison en définitive J'avais aller voir ça

Faites juste le test. Je viens de creer une table avec un champ char(10), et un index dessus. J'insere 4 enregistrements: "01", "02", "03", "04". Un premier select sans condition me les retourne dans cet ordre. Je supprime le "03", et j'insere le "05". De nouveau un SELECT * FROM matable, et resultat "01", "02", "03", "05"

 
tu remettrais en cause 7 ans d'usage de base de données

Je m'incline, j'ai fais le test avec et sans index

Mais alors, une petite question :
 
Je ne peux pas faire :
 
SELECT mes_champs FROM message WHERE id_topic = 1 par exemple ? Mon id_topic est bien un INDEX, mais les messages n'arrivent pas dans l'ordre des topics ...
 
Tu vois ce que je veux dire ?

j'ai eu un gros doute tout de meme avec les clustered. Je me suis renseigné aupres des dba. Donc pour info, l'index clustered retournera le meme resultat que l'index simple. Mais aura en plus le bienfait d'ordonner physiquement les enregistrements. D'ou un tres gros gain de temps dans le chargement des pages memoire. Mais ca n'existe pas sous MySQL.

ben merde, j'y comprends plus rien

 
Meme resultat que s'il n'y avait pas d'index.