[Optimisation] Tables avec champs textes

Bonjour,
Je n'avais pas de pb de perf jusqu'à présent, mais c'est la première fois que 'jai affaire à des tables de 100,000 enregsitrements et ça commence à ramer.

J'ai des tables de forum par exemple qui mélange des champ integer avec des champ textes.

Pensez vous que l'on puisse gagner beaucoup en séparant cette table en 2 tables, l'une contenant les donnée integer, booléen et autres types de base et l'autre contenant les textes, qui n'est utilisée que pour l'affichage final du texte ?

Ca demande un changement de conception de la base et pas mal d'effort, si j'avais des retours d'expérience sur ce sujet pour savoir si on gagne beaucoup ça me motiverai à franchir ce pas. :)

Merci!

Ce serait bien d'avoir la description de cette table.

Il faudrait p-t prévoir la création d'index sur les tables.
Personne ne me contredira en disant que les index font gagner un temps énorme lors des recherches sur la table

Voici la table, elle contient 84000 enregistrements. Ce que j'envisageais donc est de sortir "comment", "message", "title" et "adip" dans une table différente avec correspondance de l'id unique.

Je n'ai pas oublié les index.
La plupart des requête utilise "ORDER BY lastedition DESC" et c'est ça qui pombe les résultats. Quand Mysql utilise l'index "lastedition" pour réordonner, il n'utilise pas l'index pour résoudre la clause WHERE et inversement. Il est possible d'optimsier ça en mettant es index su plusieurs colones mais ma clause where peut prendre des valeurs trés diverses ce qui ne me permet pas de faire ça.

Donc la seule solution que je vois pour optimiser (peut être gagner 50% du temps?) c'est déjà de séparer le texte des champs à longueur fixe (entiers, etc...).

Vote opinion ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 id int(10) UNSIGNED No auto_increment public tinyint(3) UNSIGNED No 0 expertonly tinyint(4) No 0 message text latin1_swedish_ci No state tinyint(4) No 0 nbedition smallint(5) UNSIGNED No 0 lasteditorid int(11) No 0 comment text latin1_swedish_ci No title text latin1_swedish_ci No lastedition datetime No 0000-00-00 00:00:00 source smallint(5) UNSIGNED No 0 target smallint(5) UNSIGNED No 0 askerid int(11) No 0 userid int(11) No 0 adip text latin1_swedish_ci No
Et les index :
Code:

1 2 3 4 5 6 7 PRIMARY PRIMARY 83357 id public INDEX 2 public askerid INDEX 20839 askerid userid INDEX 20839 userid target INDEX 64 target lastedition INDEX 83357 lastedition expertonly INDEX 3 expertonly

A priori, je ne vois pas trop en quoi rajouter une jointure accélèrerait les choses, mais c'est difficile de te répondre sans connaître ta requête.