Hallo Christian!
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. Aber ich verstehe inzwsichen doch den Vorteil, denn die Tabelle enthält zwar alle Wärter der indizierten Spalte(n), aber jedes nur einmal. Somit spart man durchaus Zeit. Nur braucht manb dann ncoh die Information, in welchem Datensatz das besagte Wort jetzt vorkommt, udn hierzu braucht man IMHO eine 2. Tabelle in der der eine Verknüpfung zw. Wort und Posting_IDhergestellt, wird. Wenn man nur eine einzige TAbelle verwenden würde, dann müßte man in die eine Tabelle genausoviele Datensät7ze schreiben wie die zu indizierende Spalte Wörter enthält, und nicht jedes einmal, sondern so oft es insgesamt vorkommt, mit einer 2. Spalte Posting_ID. Oder war es das was Michael meinte, dann halt mit einem non_unique Index über die Wort-Spalte?
Und ist das wichtig?
Dachte ich...
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?
Denn wie schnell ist nochmal eine IDE Leitung?
Kommt darauf an, welcher IDE-Standard. UDMA133 kann bis zu
133MB/s transferieren.
Theoretisch, praktisch aber nur die von mir genannten gut 50 MB/sek.
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.
Wozu braucheich einen Volltext-Index bei Kategorie? Da
habe ich ja feste Strings die ich vergleiche kann. Ich
könnte sogar die Strings in Zahlen umfandeln, halt für
jede Kategorie eine Zahl das dürfte nochmal helfen!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. Aber wenn Du das sagst - gut zu wissen! Wobei da auf alle Fälle das Argument zieht, das mit der Verwendung von INT Werten an Stelle von mehr oder weniger langen Strings auf alle Fälle weniger Speicher, RAM und Bandbreit verbraucht wird, was die ganze Anwendung mehr oder weniger beschleunigen sollte, steht so oder so ähnlich im MYSQL Manual im Kapitel Server-Optimierung.
Viele Grüße
Andreas