Wir können uns daher als Regel
merken, dass Blob-Felder aus Performance-Gründen sinnvollerweise in
eine einzige Tabelle gelegt werden sollten.
Zum Abschluss möchte ich noch eine Problematik ansprechen, welche das Geschwindigkeitsverhalten von MySQL massgeblich beeinflussen kann.
Dazu sei folgender Sachverhalt gegeben: Wir haben eine Tabelle, die Tausende von Blob-Feldern (Bild- oder Sound-Daten) enthält. Zu jedem Blob-Feld wird eine Textzusammenfassung gespeichert. Die Blob-Felder benötigen etwa 95% des Datenvolumens (sagen wir mal 4 GByte). Der Text und die übrigen Statusinformationen belegen die restlichen 5%.
Nehmen wir weiter an, dass wir mit einen Volltext (Fulltext) arbeiten. Nun geben unsere User vorzugsweise 'gemeingefährliche' Wörter wie z.B. Linux ein. Dieses Wort kommt in unserer Tabelle relativ oft und quer über die gesamte Tabelle verteilt vor. Wir möchten nun immer einige Treffer gleichzeitig anzeigen. Soweit so gut, aber warum erhalten wir plötzlich saulahme Ergebnisse, wenn die User 'Linux' eingeben?
Keine Bange, das ist kein Microsoft-Werbespot, falls wir Microsoft ebenso oft in unserer Tabelle halten, würde auch 'Microsoft' erst mit einer Riesenverzögerung erscheinen; und auch das wäre kein Linux-Werbespot. Warum ist MySQL hier also langsam?
Das Problem liegt darin begraben, dass wir die Texte und Blob-Informationen in der gleichen Tabelle ablegen. Dadurch müssen wir beim Zusammenstellen der Treffer quer über die ganze Festplatte hüpfen (ok, mit 4 GByte sollte die Platte noch nicht gefüllt sein), um die Texte zusammenzutragen. Leisten wir uns den Luxus von zwei Tabellen, die wir über ein gemeinsames Feld verwalten, so liegen sämtliche Textinformationen praktisch nebeneinander (einige MBytes), sodass unser Lama umgehend wieder zum Jaguar mutiert.
Wir können uns daher als Regel
merken, dass Blob-Felder aus Performance-Gründen sinnvollerweise in
eine einzige Tabelle gelegt werden sollten.