HAAAAAAAAAAA
j'ai enfin trouvé, il a fallu que je me décide à poser la question pour trouver la réponse.
J'avais déjà lancé un rapport d'optimisation en vain, mais cette nuit je l'ai refait et je me suis apercu que certains champs (VARCHAR) étaient trop courts. Je les ai donc passés en TEXT.
Et ce matin, tout semble fonctionner correctement. Jamais je me serais douté qu'un enregistrement tronqué en longueur pourrait produire un dysfonctionnement des index.

Berzemus: oui, j'ai mis la taille mini des mots à 3

Voilà ce que ca donne avec une table supérieure à 1Go http://art-flox.com/trouvemoi.php?web=site
pas de ralentissement, elle travaille aussi vite que si elle était vide

Il y à des optimisations effectuées au niveau de l'indexage ? Stopwords ou taille minimale ?

Bonjour,

j'ai un petit problème assez pointu à résoudre:

ELEMENTS DE DEPART
- MySQL 5.0.44
- un index FULLTEXT sur 2 colonnes.
- un bot PHP qui alimente en permanence la BDD (bot d'indexation)
- BDD supérieure à 1Go
- index FULLTEXT supérieure à 280Mo
- pas de données perdues

PROBLEME
l'index FULLTEXT grossi plus vite qu'il ne devrait. Donc tous les jours le bot lance un REPAIR QUICK pour recharger l'index et lui redonner une taille plus acceptable. Si il ne le faisait pas, l'index serait capable en quelques jours de devenir plus gros que la table elle même.
Pour une petite table, c'est pas grave, pour une table qui a l'avenir fera plus de 10Go, c'est problématique de faire des REPAIR QUICK.
Pour l'instant le REPAIR QUICK prend plus de 4mn sur un C2D 2.33GHz en RAID 1.

QUESTION
que faire pour corriger ce problème ?