Als Endergebnis würde das dann so aussehen:
create index idx_suchtabelle_wort on suchtabelle(wort);
Wegen des Satzes "Das ist ein Test-Text" würde das drinnen stehen:
1, 1, 'Das ist ei'
2, 1, 'as ist ein'
3, 1, 's ist ein '
4, 1, ' ist ein T'
5, 1, 'ist ein Te'
6, 1, 'st ein Tes'
7, 1, 't ein Test'
8, 1, ' ein Test-'
9, 1, 'ein Test-T'
10, 1,' in Test-Te'
11, 1,' n Test-Tex'
12, 1,' Test-Text'
13, 1,' est-Text'
14, 1,' st-Text'
15, 1,' t-Text'
16, 1,' -Text'
17, 1,' Text'
18, 1,' ext'
Und der Select wäre so:
select * from Tabelle1 where id in (
select distinct tabelle1Id from suchtabelle where wort like concat(substring('ist', 0, 10), '%')
)
and textspalte like '%ist%';
Hier hat man sodann im Hauptselect erst wieder ein langsames like '%ist%', das ist aber notwendig, da der innere Select nur für Suchwörter mit max. 10 Zeichen funktioniert, und bei längeren Suchwörtern eventuell zu viele Ergebnisse liefert.
Andererseits sollte dieser innere Select trotzdem so gut filtern, dass der Rechenaufwand für das äußere langsame Like gegen "nicht notwendig" gehen sollte.
Auch wenn meine in der vorherigen Antwort präsentierte Lösung vielleicht nicht ganz optimal ist, sollte man hiermit das Problem nun wirklich endgültig erschlagen.
Es ist halt eine Frage des Festplattenspeichers, den man für diese Suchoptimierung bereit ist zu verwenden, und auch wie gut so eine MySQL-Datenbank mit Datenmengen im GB-Bereich umgehen kann, falls sich eine entsprechende Menge ergeben sollte.
--edit:
Wieso ich solche Beiträge hier scheibe, weiß ich selber nicht. Woanders würde man damit gutes Geld verdienen