Hi Andreas,

Was ich jetz imme rnoch nicht genau verstanden habe -
erstellt FULLTEXT jetzt eine interne Tabelle wie oben,
oder einen B-Baum?
Wo ist der Unterschied?
Ich dachte immer ein Binärer Baum würde bei einem Wort anfangen und sich dann weiter verzweigen, wie man das ganze "statisch" speichern soll ist dann so eien Sache die ich noch nicht wirklich verstanden  habe, aber das soll wohl gehen. Eine Tabelle wird ja nur linear durchsucht.

Eine Tabelle wird so durchsucht, wie der Query Optimizer das entscheidet. Wenn zu einer Tabelle kein einziger Index vorliegt, dann gibt es keinen 'schlaueren' Ausführungsplan als die lineare Suche. Liegt jedoch mindestens ein Index vor, dann _kann_ dieser Index dafür geeignet sein, einen logarithmischen Zugriff zu ermöglichen (falls er über passende Spalten geht, die in der WHERE-Klausel und/oder in der ORDER BY-Klausel verwendet wurden).

Das heisst, dass *nicht* der komplette Index im Speicher
gehalten wird, sondern nur teilweise im Speicher behalten
werden braucht.
aber welcher Teil? Woher weiß ich vorher was der User als nächstes in der DB sucht?

Woher weiß das Betriebssystem, welchen Teil eines laufenden Programms es auslagern kann, weil Du gerade ein neues Programm starten willst und dafür freien Speicher benötigst? Es weiß nicht wirklich, was Du willst - aber es wendet einen Algorithmus an, der im Mittel zu einer möglichst geringen Anzahl von Seitenaustauschoperationen führen wird.

Warum sollte sie? Dateien sind nicht sequentiell. Man darf
durchaus auch nur 10 Byte in der Mitte auslesen, oder 100
Byte am Anfang.
OK, aber woher weiß ich jetzt welche 10 Byte ich genau raushole? Wenn ich den Index nicht im Speicher habe, muß ich doch bei einer Anfrage erstmal den kompletten Index in den Speicher laden, um dann mit Hilfe des Index(denn ich einmal komplett parsen muß) den Teil der Tabellendatei zu ermitteln, den ich jetzt gut gebrauchen könnte, oder? Das Problem ist nur das der Index selbst zu groß ist für den RAM! Zumindest wenn gleichzeitig noch andere Software laufen soll.

Du kannst den Index auch in Teilen verarbeiten. Und diese Teile können sehr klein sein. Eine Index-Suche besteht aus (logarithmisch) vielen einzelnen Schritten. Jeder dieser Schritte greift nur auf ganz wenige Seiten zu - und sein Ergebnis ist jeweils eine Liste von Seiten für den nächsten Schritt. Nach und nach werden dabei immer kleinere Teile des Baums immer genauer abgegrenzt, bis am Ende eine Liste von Blättern als Ergebnis vorliegt. Ganze Teilbäume, in denen kein Treffer liegen kann, werden oftmals schon in den ersten Schritten als solche erkannt und nicht mehr bearbeitet - ihr Inhalt muß also bei dieser Suche nicht im Hauptspeicher liegen.

Unwahrscheinlich. Wenn, dann nicht merkbar. String-Indizes
sind im Normalfall Hashing-Indizes, und die sind nicht
wirklich langsamer als Zahlen-Indizes.
Ja? Das hat mir jemand mal ganz anders erklärt, dass ein String-Vergleich vor allem in größeren Tabellen erheblich länger dauert als ein Integer-Vergleich.

Selbst bei längeren und variabel langen Zeichenketten werden sich die Zusatzkosten in Grenzen halten - wobei ich Christians Vermutung, daß eine Hash-Funktion verwendet wird, nicht uneingeschränkt teilen kann, denn dann wäre der Index für Präfixzugriffe unbrauchbar, denke ich ...

Viele Grüße
      Michael