falk: Normalisierung vs. Performance

Beitrag lesen

Hallo,

Daher gilt: Spalten fester Länge an den Anfang, Varchar-Spalten ans Ende der Tabelle.
Haeufiger benoetigte Spalten nach vorne, selten benoetigte Spalten ans Ende.

Super-Hinweis, wäre mir selber nie in den Sinn gekommen, das die Feldreihenfolge so grossen Einfluss haben kann.
Damit lässt sich bestimmt einiges optimieren.

MySQL akzeptiert Tabellen mit CHAR und VARCHAR-Spalten nicht und macht aus den CHAR-Spalten ebenfalls VARCHAR. Das hat einen einfachen Grund: Besteht eine Tabelle nur aus Spalten fester Länge (INT, CHAR usw.), kann man beim Suchen die Zeilen schneller abgrasen. (Man sucht zB. nach Inhalten der 2. Spalte, dann findet man diese genau aller x Bytes). Das ganze hat sich erledigt, sobald eine der Spalten keine feste Länge hat.

Man sollte also Überlegen: alle Spalten als CHAR werden schneller durchsucht, brauchen aber mehr Speicher und vor allem mehr Ladezeit. Tabellen mit VARCHAR-Zellen verursachen mehr Suchaufwand, werden aber schneller in den Speicher geladen. Außerdem verursachen UPDATES einen großen Overhead, wenn zB. die neue VACHAR-Länge größer ist als die alte, und die Zeile deshalb ans Datenbankende geschoben wird. Auch alle anderen Insert- oder Indexaufgaben werden vermutlich langsamer.

Varchar-Spalten bis Länge 3 werden übrigens als CHAR behandelt.

soviel zur Theorie.. viel Spaß beim optimieren :o)
Falk