Index FULLTEXT qui grossi trop vite

17 nov. 2008, 19:31

Bonjour, j'ai une petite base MySQL avec un index FULLTEXT sur 2 clefs.
Lors de nouveaux INSERT, l'index FULLTEXT grossi c'est normal, mais trop. En effet si j'utilise REPAIR TABLE, elle diminue en taille.
Sur d'autres bases pour d'autres scripts, le problème n'apparait pas.

Est ce que le problème du fulltext qui grossi peut être lié au fait que je n'y fait que des INSERT et aucun UPDATE ?

17 nov. 2008, 20:40

salut salut, Pour bien te répondre, tu veux bien juste nous mettre la structure de ta table (le "create table"). Ce sera plus facile pour voir ce qui pourrait chiffonner.

18 nov. 2008, 00:19

Code : Tout sélectionner

-- --------------------------------------------------------

--
-- Structure de la table `ld_base`
--

CREATE TABLE IF NOT EXISTS `ld_base` (
  `id` smallint(5) NOT NULL auto_increment,
  `guid` varchar(250) NOT NULL,
  `flux` tinyint(3) NOT NULL,
  `title` tinytext NOT NULL,
  `description` text NOT NULL,
  `link` varchar(220) NOT NULL,
  `img` text NOT NULL,
  `pubdate` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `guid` (`guid`),
  FULLTEXT KEY `FullText Title/description` (`title`,`description`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=4011 ;

Voilà, c'est la table d'un annuaire de sites et de flux RSS
Dans le title et description on a le titre du site et sa description courte < 1000 caractères

Le FULLTEXT grossi trop vite, la fonction OPTIMIZE TABLE n'y fait rien, je suis obligé après plusiurs INSERT de faire un REPAIR TABLE QUICK qui reste potentiellement dangereux et demande pas mal de ressources.

Exemple sur le grossissement:

quand ma table fait 1,5Mo et mon FULLTEXT fait environ 1.4Mo
si je fais plusieurs INSERT, imaginons que la table fasse 2Mo, le FULLTEXT fera 2.1Mo (plus gros que la table)
Je fais un REPAIR TABLE, le FULLTEXT redescend à une taille inférieure à la table, ce qui est plus normal

18 nov. 2008, 17:01

Hum, je ne suis pas sur que de créer un index fulltext sur deux colonnes est une idée optimale..

Certes, c'est sympa, et vite fait, mais personnellement je préfère, dans des cas ou plusieurs champs sont susceptibles d'êtres indexés par fulltext, de créer une table supplémentaire, avec dans un champ tout le contenu possible joliment concaténé, et dans un autre champ le pointeur (l'index).

Enfin, c'est comme ca que je fais, et je sais que ça ne m'a jamais causé de soucis, que du contraire, puisque c'est bien plus facile à gérer par après.

18 nov. 2008, 17:09

Bonne idée qu'il faudrait que je test. Le seul soucis pour l'instant c'est que chez OVH un fulltext n'est pas pris en compte dans le quota (taille maxi de la base), si je crée une table pour les mots clefs, j'attendrai ce quota plus rapidement.

Mais je vais quand même faire des tests. Merki

Index FULLTEXT qui grossi trop vite

Qui est en ligne