DEDIBOX-NEWS.COM

ComandoCool · 2006-07-28 01:18:16

Bonjour,

J'ai actuellement un service de tchat qui a plusieurs membres, chacun a ses messages j'ai donc deux tables 'membres' & 'messages'.

La table 'messages' a cette forme :
id_membre
id_message
message
etc ..

Son index est comme ceci :
Primary sur id_membre & id_message
Index sur id_membre

Seulement j'ai l'impression d'avoir fait une bêtise, en effet ne sachant pas ce qu'est primary je l'avais mis au hasard, et par chance avec cette configuration chaque id_message augment selon le membre (le membre 1 voit ses messages avoir l'id 1 puis 2 puis 3, etc et le membre 2 voit ses messages faire 1,2,3,4, etc au lieu de suivre genre 4,5,6, etc).
Maintenant je ne sais pas comment je pourrais configurer tout ça et si ça va vraiment changer quelque chose car mon serveur commence à saturer et à être long.

Merci de votre aide.

PS: j'ai ajouté l'index aujourd'hui je n'ai pas eu le temps de voir les changements.
Autre chose, j'ai remarqué qu'on pouvait mettre les tables en mémoire, pour faire du tchat est-ce bien ?
Voici au cas où mon config apache
<IfModule prefork.c>
StartServers 20
MinSpareServers 50
MaxSpareServers 70
MaxClients 256
MaxRequestsPerChild 2000

Calimero · 2006-07-28 08:28:21

Bon, même si les infos que tu donnes sont partielles, on peut déjà dire que le 'PRIMARY' t'aurais plutôt du le mettre sur id_message seul.

PRIMARY indique que la colonne désignée est la clé primaire de la table, en conséquence, tu as alors un index qui contrôle l'unicité des valeurs dans cette colonne (chaque id_message doit être unique pour pouvoir identifier chaque ligne du tableau par son id_message). Ajoutons à celà que le champ id_message a été créé avec auto incrémentation.

Dans un premier temps, je corrigerais l'histoire de la clé primaire sur id_message et id_membre.

Ensuite, il faudra que tu cibles les requêtes qui sont trop lentes, puis que tu fasses du "EXPLAIN" dessus.

Dans mysql, quand tu fais "EXPLAIN SELECT * FROM table WHERE champ = val", mysql te donne des infos sur comment la requête est executée, quels sont les indexes potentiellement utilisables et quels sont les indexes réellement utilisés, ... Et parfois, c'est un peu la douche froid: genre du tablescan à gogo sans utiliser le ou les indexes présents...
Bref: http://dev.mysql.com/doc/refman/4.1/en/explain.html

ComandoCool · 2006-07-29 13:33:32

Donc seulement une clé "primary" sur id_message, ok.
Seulement il n'est pas en auto incrémentation, les id_message ne sont pas uniques, si je supprime la clé primaire sur id_message et id_membre et ajoute un auto inc est-ce que ça pourra fonctionner ?

Je pensais que le plus simple serait de créer un copie de la table pour faire des tests pour ne pas géner l'utilisation actuelle.

Pour explain j'ai essayé bien avant pour optimiser, mes requêtes sont propres, sachant que c'est du tchat je fais seulement un where id_membre=id avec un order by date et biensur un limit 0,X

Calimero · 2006-07-29 15:34:21

C'est effectivement beaucoup plus simple à gérer si la colonne est en auto incrément.

Oui, testes ton application sur une une base différente (si l'appli tourne déjà en prod) avant de "porter" les changements dans la base principale.

ComandoCool · 2006-07-30 14:28:51

J'ai mis primary sur id_messages avec auto_inc et index sur id_membres, résultat avec explain : même vitesse de traitement. Donc ce n'est pas plus rapide, juste plus propre

Calimero · 2006-07-30 14:30:39

En terme de contraintes d'intégrité, c'est pas pareil.

ComandoCool · 2006-07-30 14:36:43

Donc il y a un avantage ?

Et concernant la clé unique, dans quel cas l'utilise-t-on ?

Calimero · 2006-07-30 14:39:08

Si tu mets une contrainte d'unicité sur id_A et id_B, ca veut dire que chaque combinaison id_A + id_B doit être unique. Par contre, ca permet d'avoir ca:

id_A | id_B
42 | 01
42 | 02
43 | 01
...
Ce qui ne paraît pas être le comportement souhaité.
Donc tu mets ta clé id_message en auto incrément, primary (et donc unique).

ComandoCool · 2006-07-30 14:49:15

Ok, je vais appliquer cela à la table concernée cette nuit, merci pour tes explications

DEDIBOX-NEWS.COM

#1 2006-07-28 01:18:16

Configuration table MySQL correcte ?

#2 2006-07-28 08:28:21

Re: Configuration table MySQL correcte ?

#3 2006-07-29 13:33:32

Re: Configuration table MySQL correcte ?

#4 2006-07-29 15:34:21

Re: Configuration table MySQL correcte ?

#5 2006-07-30 14:28:51

Re: Configuration table MySQL correcte ?

#6 2006-07-30 14:30:39

Re: Configuration table MySQL correcte ?

#7 2006-07-30 14:36:43

Re: Configuration table MySQL correcte ?

#8 2006-07-30 14:39:08

Re: Configuration table MySQL correcte ?

#9 2006-07-30 14:49:15

Re: Configuration table MySQL correcte ?

Pied de page des forums