Reprise du message précédent :

ben j'ai testé, ca prend quelques secondes, et ca seulement pour un seul mesage, puis faut recommencer pour chaque post supprimé

Les posts supprimés sont le plus souvent en fin de topic, sla dit.
Qqs secondes, c'est avec la colonne indexée ?

ouais mais bon Google existe

Corbeille

Et avec un index dessus?

avec myisam un count sur une table est immediat, et c'est quasiment valable aussi pour un count sur un index. Alors qu'innodb c'est très lent, ce qui oblige à maintenir des compteurs à part

en fait ca serait plus simple de se pencher sur le code source de MySQL et notamment des bitmap qui permettraient de gérer de façon optimale les LIMIT et qui existent, mais pas encore utilisés pour ce genre d'optimisation.

 
Hum ... Ça c'est intéressant ... Surtout depuis que j'ai tout revu je n'ai plus de clé étrangère... Je sans doute virer les compteurs et passer sous MyISAM alors

je parlais du cas avec un index dessus

...et tu essaies de garder la cohérence des données uniquement avec ton code php?

C'est comme ça avec tous les forums exploitant les tables MyISAM tu sais

bah oui, justement.

Toute façon c'est une vraie jungle le dev ouaibe (enfin comme bcp d'autres domaines sans doutes ^^)
 
Mais quoi qu'on utiliser, t'auras toujours quelqu'un pour te faire comprendre que c'est mal

en php

Non, ça c'est pas une jungle, c'est un marais.

En suivant ce topic ça m'a donné envie de jouer un peu avec MySQL.
 
Par défaut j'ai utilisé InnoDB parce qu'il fallait bien que je choisisse un moteur.
 
Sur une table articles qui comporte 100.000 entrées (merci LOAD DATA INFILE qui m'a fait ça en 5s), une requête:

prend 0.5s.
 
J'ai alors décidé de créer une table commentaires, et j'ai mis 1.000.000 d'entrées, soyons fous!
 
Et bizarrement la même requête donc sans même aller pêcher dans commentaires, me prend maintenant 6s. Comment ça se fait? C'est InnoDB qui fait ça? Passer à MyISAM amélioreraient sensiblement les performances?
 
Parce que là je fais une requête toute bête, je vois pas comment elle pourrait être optimisée.

ta colonne user_id est bien indexée?

edit: et t'as déclaré la colonne user_id comme étant une FK sur user.id ou pas non plus?

En n'utilisant pas l'*

Là en l'occurrence je ne vois pas le rapport entre Php et les moteurs de stockage de MySQL

user_id est bien indexé, par contre pour le FK je sais pas où je vois ça dans CocoaMysql, je vais réinstaller phpmyadmin je sais mieux m'en servir, mais normalement la FK devrait être gérée par Rails puisque je l'ai spécifié dans le fichier de migration depuis son passage en version 2.
 

Effectivemment je suis passé de 6s -> 4.5s.
 
Par contre là je viens de passer à l'étape supérieure avec:

Avec une table qui possède 1M d'entrées, ça prend 20s  

article_id aussi est bien indexée ?

C'est quoi ton serveur ? Combien de lignes exactement sont retournées ?
Parce que, bien que ça semble un peu lent, avec une table d'1M d'entrées, si c'est un petit serveur, ça peut sembler normal !
 
Et, en plus de vérifier les index, tu peux aussi vérifier les plans d'exécution, les stats, toussa ! Ca t'apportera peut-être des pistes pour améliorer ça !

Fais voir les plans d'exécution effectivement, c'est ça qui t'indiquera si tu peux optimiser et où.

Bon j'ai remodifié par mal de choses.
 
Entre autres, les compteurs ne sont plus calculés à chaque insertion pour mettre à jour la/les tables parentes, mais avec des jointures et du COUNT, et c'est vrai que c'est très rapide (les count sont instantanés, même sur les grosses tables)
 
Merci Joce

en quoi c'est plus rapide de faire des jointures pour des compteurs, lors des insertions pas compris ce que tu as fait là

Avant, quand j'insérais un post :
 
Topic : posts = posts + 1;
Forum : posts = posts + 1;
Category : posts = posts + 1;
Members : posts = posts + 1;
 
Mais vu que le compteur devait être maintenu à jour, un delete de post sous entendait :
 
Topic : posts = posts - 1;
Forum : posts = posts - 1;
Category : posts = posts - 1;
Members : posts = posts - 1;
 
Et un delete de topic :
 
Forum : topics = topics - 1;
Forum : posts = posts - X;
Category : topics = topics - 1;
Category : posts = posts - X;
Pour chaque members qui avait posté dans le topic : posts = posts - X;
 
Donc ça faisait des calculs sans arrêt

et maintenant tu fais quoi ?
je comprends qu'au lieu de récuperer le nombre de posts X d'un topic, tu fais un count sur ce topic pour avoir le nombre de posts.. c'est pareil non ?
en meme temps, je suis crevé, je rentre du taff après 13h de boulot tooday

Si j'ai compris son truc, maintenant il n'utilise plus de compteurs mais recompte à chaque fois le nombre de posts quand il fait le listing ? Ca alourdit sûrement (jointures) si c'est ça car chaque personne lisant un sujet lance des COUNT à tire larigot, nan ?

Ben avant si j'affichais la liste des forums par exemple, je faisais (en gros) :
 
SELECT id, name, topics, posts FROM forum
 
Puisque j'avais un champ pour le compteur de topics, et un pour le compteur de post
 
Maintenant j'ai viré les champs (donc ceux du dernier posteur, du titre du dernier post, avec leurs ID respectifs), donc quand j'affiche la liste des forums, il faut que je fasse une jointure, et des COUNT, pour savoir combien il y a de topic/post dans chaque forum.
 
Idem à l'affichage des topics, pour savoir combien il y a de posts, et le dernier post/posteur de chacun d'entre eux

 
Oué voila

Je vais reprendre à zéro, parce que je me suis planté en répondant à certaines questions.

Alors j'ai lancé Mysql Administrator, et articles.user_id ne semble pas être indéxé et user.id n'est pas déclaré comme FK non plus! Normalement Rails était censé faire ça automatiquement. Sinon l'instruction SQL à taper pour vérifier les index et les FK c'est quoi déjà histoire que je confirme à la main?
 

D'après Mysql administrator, je n'ai pas l'impression que ce soit le cas. Enfin ce soft ça fait 2 jours que je l'ai installé je sais peut-être pas forçément bien interpréter ce qu'il m'affiche.
 

100 lignes sont renvoyées, mais au final y'aura un filtrage supplémentaire. Ma bécane de dév est un G4 1Ghz. Le serveur final sera un Kimsufi XL, tu penses que ça suffira pour faire traiter une table aussi grosse? C'est à peu près la taille maxi de la BD que je vise en condition réelle d'utilisation, avec environ une dizaine de connections par seconde à mon site aux heures de pointe.
 

C'est quoi le plan d'éxecution? j'ai fais un petit google mais rien de satisfaisant est sorti.
 
Déjà je dois tirer au clair cette histoire d'index et de FK, c'est pas normal Rails aurait du s'en charger tout seul puisque j'ai respecté les conventions  

> Mets un index sur article_id
> Pour le plan, tu fais un "DESCRIBE ta_requete" je crois
 
Par exemple :
 
DESCRIBE SELECT machin, truc LEFT JOIN bidule ON ...

0.28 secondes pour afficher 200 forums, avec le calcul du nombre de topics et post pour chacun d'eux, ainsi que le titre et l'id du dernier post, ainsi que le titre et l'id du dernier posteur.

Alors déjà

 
Ca veut dire que user_id n'est pas déclaré comme clé étrangère me trompé-je?

C'est alors très certainement + lourd à l'usage, car le ratio insertion/lecture et delete/lecture tendent vers 0. Les compteurs sont "peu fréquemment" mis à jour et leur rapatriement est + simple et directement dans la foulée de la requête sur la table TOPICS par exemple. Tu fais sans cesse des calculs implicites et des jointures avec ta méthode. C'est tjs une histoire de compromis quoi . Y reste le compteur de vues maintenu en dur

Y'a pas d'index sur ton user_id

Et il me semble que user_id n'est pas non plus déclaré comme Foreign Key Constraint, donc en fait je me tape InnoDB sans même tirer profit de ses capacités...

Joce disait justement le contraire ! Un COUNT sur une table myIsam avec de bons index est très très rapide, c'est pour ça que Yell a choisi de tester comme cela, et d'après ce qu'il dit, c'est convaincant.

Ça vient de quoi la "perte" sur une table vide ?
 
Sur table avec du contenu, je crois que ce sont les champs qui ne sont pas rempli, entre autres, non ? Genre un champ "CHAR 30" avec 20 octets de datas dedans, ça faut 10 octets de perte, c'est bien ça ?
 
Mais sur une table vide ...

C'est dû aux suppressions des données de la table, ça laisse des "trous" qui sont récupérés soit quand tu réinserts des données dans la table, soit que tu "vacuum" ta table (ça s'appelle "optimize" dans Mysql je crois).