Leider habe ich beim (vergeblichen) Versuch einen zusätzlichen Index auf der Tabelle hinzuzufügen nach 2 Stunden etwas demotiviert den entsprechenden ALTER TABLE Query angebrochen und dabei die Index-Datei der Tabelle zerhauen.
Man nehme also eine MyISAM-Tabelle mit knapp 3 Millionen Datensätzen und kaputter Index-Datei, einen Rootserver und extrem viel Zeit. Der Volltext-Index auf der Tabelle kommt auf eine Größe von ca. 5,6 GiB.
Bei 5,6GiB Index-Größe war mein erster Ansatz
REPAIR TABLE searchindex
leider eher ernüchternd. Dauert mit Standardkonfiguration (with Keycache sei Dank) einfach stur zu lange.
Nach etwas Googlen wurde ich fündig, das kleine Tool myisamchk liefert genau was ich brauche. Der Rebuild dauert zwar immer noch ziemlich lang, allerdings lassen sich hier, da das Tool über die Shell gestartet wird, sämtliche Caching und Buffer-Einstellungen manuell setzen, überschreiben und konfigurieren.
Nach viel Geduld und einigen (vielen) Fehlversuchen kam der folgende Aufruf raus:
myisamchk --ft_min_word_len=2 --tmpdir=/tmp/ --key_buffer_size=1024M --sort_buffer_size=1024M --read_buffer_size=1M --write_buffer_size=1M --sort-recover --verbose searchindex
Die wichtigsten Einstellungen sind –sort_buffer_size=1024M, –key_buffer_size=1024M. Im Endeffekt die 2 Einstellungen mit denen ich verhindere, dass der Rechner sich durch übermäßiges Swapping ins Nirvana verabschiedet.
Die Einstellung –sort-recover legt fest, dass der MySQL-interne Sortier-Algorythmus verwendet werden soll, um den entsprechenden Index aufzubauen. Der Key-Cache (standardmäßig verwendet wenn der Speicher alle ist) hingegen, würde ca. den Faktor 20 an Zeit brauchen um den selben Effekt zu erzielen.
Aktuell läuft die Query noch, ist aber auf dem 9. Index der Tabelle (ich meine das ist der Volltext) ca. 50% durch gelaufen. Ich hoffe wenn ich morgen aufsteh ists fertig 
