Bonjour,
 
J'ai une table d'environ 500.000 entrées (350 mo), très visitée (pas mal de lecture, ajout, effacement).
 
C'est une table "messages", il y a
 
numero (int)
login (char)
expediteur (char)
sujet (char)
message (longtext)
date (datetime)
etat (tinyint)
 
index sur login et etat
 
Vous vous doutez bien qu'elle prend beaucoup de ressources, alors je voudrais savoir si en bougeant la colonne "message" dans une autre table ca allait pouvoir accellerer les processus ? Dans le cas contraire, vous avez une methode plus intéressante ?
 
Merci.

y a un moyen simple de le savoir

Je serais toi, je ferais des tables différentes : une table utilisateur et une table messages par exemple ...

 
Faire ca ne servirait à rien puisque le seul problème dans la table est le LONGTEXT, si je n'avais que des CHAR il n'y aurait pas de soucis au niveau de la vitesse en ajout et effacement. Il faut que j'isole le longtext tout seul.

perso j'ai pas de probleme de perfs avec cette methode

Ouai mais tu tournes peut être pas sous ASP avec un site qui fait 12.000.000 de pv/mois

je tourne pas en ASP non, mais je pense que le forum sur lequel tu postes fait plus que 12 000 000 pv/mois

et avec tout ca, t'aurais eu le temps de tester depuis

Je ne vois pas le rapport avec le forum. De plus toutes les pages du forum sont sauvées en HTML ce qui fait gagner beaucoup de ressources cpu, et j'imagine qu'il tourne sur linux, ce qui n'est pas pareil que windows 2000.
 
HappyHarry tu essayes de dire quoi ?

qu'en une journée tu aurais largement eu le temps de tester par toi meme laquelle des deux solutions est la plus rapide

parce que le forum c'est moi qui l'ai concu donc je sais comment il marche et je connais les structures que j'utilise avec MySQL.
Quand aux pages, elles ne sont pas en HTML, mais bien en php, c'est juste le modrewrite qui est utilise.

C'est pas aussi simple que ca, je dois faire ces tests avec le maximum de gens sur le site pour me rendre compte de l'impact ou non de la transformation, ce qui implique en cas d'échec que je revienne au modèle précedent avec la charge de réassembler les bases de données ce qui sur une base de 500.000 entrées devient plus compliqué que de les séparer. Je pense que créer 2 tables est la meilleure des choses, mais je suis venu ici pour savoir si quelqu'un pensait le contraire et avait une autre solution car je ne me qualifie pas comme un expert en mysql, y'a sans doute des petits trucs que je ne connais pas et que d'autres connaissent.

moi je dis que ca ne changera pas grand chose parce que j'imagine que tu rapatries toutes les infos en meme temps et pas uniquement le message. Donc tu vas faire une jointure qui va rien t'apporter a part encore une diminution des perfs.

Ok pour le rewrite que je ne connais guère puisqu'on n'a pas ca en standard sur ASP. Mais tu ne peux pas comparer l'incomparable, encore si j'étais sous CHILI ASP peut être qu'on aurait pu comparer, mais face à un windows déjà lourd par lui même c'est pas la peine mais je reste néanmoins persuadé qu'il peut dépasser les 12M avec quelques transformations puisque c'est surtout une table qui fait ralentir le système.

mais tu comptes gagner quoi en separant ta table en deux
Ta table dans MySQL est une table dynamique c'est a dire que chaque champ prend la place optimale sur le disque.
T'as regarde du cote de tes indexs plutot ?

je rappatrie dans un premier cas tout sauf le message, pour afficher la liste des sujets, ensuite je rappatrie tout pour la consultation d'un message. J'avais lu qu'un VARCHAR ou un LONGTEXT (ou tout autre type avec taille variable) étaient la cause de nombreux crash de tables (ce qui m'arrive aussi) et qu'il fallait privilégier les CHAR qui eux ont une taille fixe, surtout quand la table est souvent modifiée. Je pense que pour l'organisation de la table, sa mise en forme lors de MAJ, que cette solution peut être plus rapide car elle se saisit de moins de données d'un coup

heu remarque attends y a un truc que j'avais pas vu dans ta structure, desole
separe la table en deux effectivement
 
(premiere table statique, deuxieme table dynamique)

Mes index sont réduits au minimum. Je compte permettre à MYSQL de manipuler moins de données d'un coup, modifier 2 tables de 170mo est sans doute plus rapide que de modifier une table de 350 mo ?

Perso, j'ame bien divisé fortement mes tables de façon a ce qu'il n'y ai jamais de répétition. J'enlèverais donc login, expediteur et message de cette table.

Je compte en fait faire ces deux tables car plus pratique dans mon cas :
 
numero (int)  
login (char)  
expediteur (char)  
sujet (char)  
date (datetime)  
etat (tinyint)  
 
 
numero (int)  
message (longtext)