La vraie question est: existe-t'il une relation entre les tables ? car jusqu'à présent je n'en vois pas dans ton code. Dans ce cas tu aurais mieux fait d'exécuter une requête par table, sinon il serait bon de poster la structure (simplifiée, inutile d'inclure tous les champs) des tables en questions et la vraie requête que tu utilises.

Quant à utiliser une table de recherche, je suis 100% pour. (d'ailleurs iclo, si tu voulais développer "ça devient très vite l'usine à gaz" ça m'intéresse) Pour indexer le texte contenu dans la table Machin la structure des tables pourrait ressembler à: (clés primaires en gras)

Table Machin
machin_id INT
machin_text TEXT

Table words
word_id INT
word_text VARCHAR(20)

Table match
machin_id INT (->Machin.machin_id)
word_id INT (->words.word_id)

Tu peux avoir une description de cette approche dans cet article de Frédéric Brouard [ Indexation documentaire & bases de données ].

Reste un problème: ce modèle ne peut servir qu'à indexer une seule table. Pour en indexer plusieurs tu dois avoir recours à une troisième table d'indexation (et modifier la seconde):

Table documents
doc_id INT
doc_type ENUM('Machin', 'Truc')
foreign_id INT (->Machin.machin_id, ->Truc.truc_id) (ce champs ne peut pas être une contrainte étant donné qu'il lie la table à plusieurs autres tables)

Table match
doc_id INT (->documents.doc_id)
word_id IN (->words.word_id)

Petit exemple, pour retrouver tous les documents (posts de ton forum, bio de tes utilisateurs, description d'un produit, etc...) comportant les mots 'flan' (word_id 8) ET 'caramel' (word_id 12) tu exécuteras: Ensuite, grâce aux IDs et au type de document doc_type tu pourras récupérer les textes en question si tu souhaites les afficher. Le cadeau bonux de cette méthode c'est que si quelqu'un tape un mot qui n'existe pas tu le sais très rapidement car il n'est tout simplement pas indexé. Si tu as des questions spécifiques j'essaierai d'y répondre quand je repasserai.

La table contenant les mots clé devient très vite très lourdes avec quasiment un tupe par mot. Et finit même par représenter la majeur partie du volume de la DB.
Je n'ai pas de solution idéale à proposer, je le reconnais, vu que je n'ai jamais eu le problême , mais je m'interroge sur la faisabilité de ce sytême sur des sites à très gros volume.

Concernant la taille, c'est sûr que ça grossit vite... récemment je faisais des tests sur les tables d'un gros gros forum (3,1 millions de posts, 30 millions de rows dans la table "match") et les tables d'indexation font ~1Go, à comparer à un index Full-Text qui ne prendrait que ~350Mo. Avec des indexes compressés on gagne pas mal de place (dans les 20% je pense) mais ça reste de toute façon beaucoup plus gros qu'un index Full-Text du fait de la nécessité de stocker les informations en double: données des tables + index des tables là où un index Full-Text par définition ne stocke que l'index de la table.

En fait ce n'est pas une usine à gaz (une usine à gaz c'est un truc vieux, un peu poussif et qui sent pas bon) ce serait plutôt... euh... des éoliennes: c'est élégant, ça produit du courant mais c'est vrai que ça bouffe de la place.

Et bien merci à vous.
Hubert Roksor, le lien que tu m'as donné m'a l'air fort intéressant.

Et... euh, c'est sur quelles tables déjà que tu veux effectuer ta recherche ?

$_POST["clef"]="exemple";

Euhhhhh , depuis quand on peux réaffecter une variable issue d'un formulaire ???

C'est bien gentil "beubeu" mais un mois et demi après, c'est peut-être un peu tard pour répondre à ce post...