Re: [1/2 OT] MySQL Storage Files
Hagen Kuehnel schrieb:
On Wed, Feb 16, 2005 at 07:56:37PM +0100, Peter Blancke wrote:
> Das ist eine Möglichkeit, hat aber auch einen Nachteil: der Dump macht
sehr viel overhead und er dauert länger als ein binäres Kopieren. Bei
Gewährleistung der Datenkonsistenz bedeutet das ein umfangreicheres
Wartungsfenster. [...]
Genau, selbiges hab ich auch überlegt. V.a. da der Server wohl nicht die
nötigen Ressourcen für einen Dump birgt.
[..]
Besonderer Augenmerk gilt hier diesen Files:
#sql-316_b7.MYD
#sql-316_b7.MYI
#sql-31b_4ea.MYD
Die kommen mir a) neu vor, b) finde ich keine Info dazu und c)
sind die ziemlich groß.
Du suchst Grundlagen ueber Binary-Trees in Datenbanken und deren
Ablage in Dateien.
Warum nicht einfacher, offizielle Erklärung von MySQL AB
"MySQL legt jede Datenbank als Verzeichnis unterhalb des MySQL-data-
Verzeichnisses an und Tabellen innerhalb einer Datenbank als Dateien in
dem Datenbank-Verzeichnis. "
Das ist klar, trotzdem danke.
Auch wenn es schwer zu glauben ist, heißen Tabellen des OP "sql-316_b7"
oder "sql-31b_4ea".
> Tabellen des OP
? OP ?
Die Groesse dieser Dateien hat nichts gemeinsam mit den eigentlichen
von Dir dort hineingefuetterten Daten.
Soll das heißen, dass die größe nicht _identisch_ ist, mit den
ursprünglich an die DB übergebene Datenmenge? Weil, die Größe dieser
Dateien ist ja sehr wohl davon abhängig, ob und welche Daten er in den
Tabellen speichert.
Genau hier liegt der Knackpunkt. Die effektive Datenmenge beträgt wie
gesagt ca. 700 MB, mehr 'tables' bzw. Daten kann ich nicht abrufen.
Effektiv belegt das directory jedoch mehr als 3 GB, was mit o.s.
Erklärung von MySQL AB nicht wirklich vereinbar ist.
Woher also kommen diese Files? Da deren Filename mit einem '#' beginnt,
könnte man vermuten, dass das "versteckte" (für den DB-Server) Tabellen
sind. Nur finde ich leider nichts dazu...
Vielen Dank,
n8,
Andi
Reply to: