ABAKUS

Hi,

eine meiner MySQL Tabellen hat seine Größe von 2GB erreicht. Da die Tabelle jedoch größer wird, habe ich mich etwas informiert.

https://netmirror.org/mirror/mysql.com/ ... table.html

Laut der Seite muss ich meine Tabellenstruktur nur leicht ändern, indem ich AVG_ROW_LENGTH und MAX_ROWS anpassen.

Nun Frag ich mich welche Auswirkungen diese beiden Werte später auf die Performance haben. Sollte ich MAX_ROWS erstmal nur auf einen etwas höheren Wert setzen und dann später erneut anpassen oder gleich auf dem maximalen Wert den ich irgendwann mal vermuten könnte.

Das Gleiche bei AVG_ROW_LENGTH. Der jetzige Wert von Show Table Status bei AVG_ROW_LENGTH lautet 1011. Da ich wegen der vollen Tabelle nicht alle Felder ausfüllen konnte, ist der Wert in Wirklichkeit höher. Kann es größere Auswirkungen haben, wenn dieser Wert zu groß oder zu klein ist?

Vielleicht hat hier ja jemand etwas mehr Erfahrung und kann mir dazu was sagen.

Phil

P.s. Die Tabelle verwendet Text/Blob Felder

Wenn Du
a) ein Linux mit der Möglichkeit, Dateigrößen > 2 GByte zu halten oder
a1) ein Windows mit NTFS und

b) ein frisches MySQL passiert gar nichts.

MySQL Version 3.22 hat eine Begrenzung auf 4G pro Tabelle. Mit MyISAM ab MySQL Version 3.23 wurde die maximale Tabellengröße auf 8 Millionen Terabytes (2 ^ 63 bytes) hochgeschraubt.

hm, da hab ich wohl wichtige daten vergessen.

es handelt sich bis um eine lokale datenbank die be mir unter windows xp pro läuft. das dateisystem ist ntfs.

meine mysql version ist 4.1.8-nt.

dennoch kommt bei 2gb die meldung "table is full". größere tabellen werden ja unterstützt, nur muss man die beiden werte oben anpassen und da fragte ich ja nach erfahrungen wegen der performance.

phil

so, ich habs einfach mal ausporbiert mit folgendem sql:

ALTER TABLE products_data MAX_ROWS=3000000 AVG_ROW_LENGTH=1050;

Momentan umfasst die Datenbank ca. 2 Millionen Einträge und der Average/Row liegt bei 1010.

Wenn ich jetzt eine Abfrage ausführe, die vorher 15s benötigt hat, kommt er jetzt nach mehreren Minuten (973s) zu keinem Ergebnis. Scheint wohl echt eine probiersache zu sein

Phil

wie wäre es mit einer Tabellenaufsplittung oder Strukturänderung.

hi,

eine splittung auf mehrere tabellen wäre sicherlich möglich, nur ist dass nicht schön, wenn es auch anders geht. mysql macht es ja möglich, die frage ist nur wie. werde wohl mit den werten noch etwas experimentieren und hoffen dass sich noch jemand meldet.

wenn nichts mehr geht, wird das wohl die notlösung sein, bzw. der mysql support.

phil

mal noch eine kurze frage am Rande wieviel Spalten hat den die Tabelle? und sind dort auch blob Felder dabei?

das kannst du vergessen. die isam-tabellen schaffen max 4GB, je nach Betriebssystem. Und die sind selbst nicht sicher, also mit deinen 2gb bist du gut dabei. und für 2 mil. einträge 2 gig, finde ich ein wenig sehr heftig. es wurden datentypen entworfen um diese auch zielgerecht einsetzen zu können.

du kannst die tabelle jetzt zwar noch etwas komrpmieren, aber davon würde ich bei der datenmenge abraten. ich bin mir fast sicher, dass du die datenbank, bzw. die tabell völlig redundant aufgebaut hast. das wäre jetzt die quittung dafür. sorry aber so ist es.

@marc75

spalten sind es bisher 65 (mehr als 70, sollten es auch nicht werden), wobei je nach datensatz 80% immer verwendet werden. es sind blob felder mit dabei, mehrere sogar.

@FLOPPER

das ist nicht ganz korrekt. myisam geht auch größer als 4gb

https://jeremy.zawodny.com/blog/archives/000796.html

Werde es halt weiterhin probieren, im notfall werden einige Spalten in eine weitere Tabelle ausgelagert. Die Tabelle ist so groß, weil entsprechend viele Produktinformationen vorliegen. Da Qualität an erster Stelle steht, werden all diese Informationen gespeichert.

Phil

@pvdb
Das ist nicht richtig. Hast du mehrere CPUs in der Kiste? Lese doch einfach mal da mysql nach. da wirst du alles finden, was dfu brauchst.
zweite anmerkung. warum lagerst du nicht die verschiedenen infos in verschiedenen tabellen (OOP) aus und bindest diese über die IDs.

nicht böse sein, aber ich würde es so machen, sonst hast du bald wieder ein problem. nach den regeln der OOP aufteilen, das ist das rezept.

noch ne frage, warum brauchst du blobs?

in der tabelle sollen utf8 texte angelegt werden und wenn ich text felder anlege die utf8 kodiert sind, macht er daraus automatisch blobs.

lokal auf dem rechner eine cpu, auf dem production server zur zeit zwei cpus. aber ein eigener datenbankserver mit zwei cpus wäre bei bedarf auch möglich.

wie weit ich einige daten in andere tabellen auslager, muss ich mal schauen.

phil

@pvdb: würde ich auf jeden fall machen, sorgt dann auch für mehr speed. gut die abfragen werden was komplexer, abeer muss man durch

Abfrage Stichwort: JOIN

Tabellen Aufteilung zum Beispiel:

tab_artikel
id | INT Feld 1 | INT Feld 2 | usw.
tab_artikel_beschreibung
artikel_id | Varchar Feld 1 | Text Feld 1 | usw.


Abfrage ungefähr so: Wie die Abfrage richtig geht schaue mal in ein entsprechendes Forum oder so.

Und Blob Felder sollte man meiden wo es nur geht.
Dann auch ruhig mal bei mysql.de nachlesen wie man eine Tabelle schlank hält, indexe verwendet etc.

hi,

hab die tabelle schon schlank gemacht, einige empfehlungen die nun wirklich nie im leben brauche wurden minimiert. die größe wurde um 50% gesenkt, mal schauen das noch geht. drei spalten noch im visir.

joins sind kein problem, allerdings nutze ich die andere art.

index und fulltextindexe für die berechnungen sind gesetzt.

phil

so, dass mit den 2gb war nen dummheitsfehler von mir. 4gb sind ohne probleme möglich. sollte die 4gb grenze sich einages tages doch noch ändern (vermutlich frühstens in 3-5 Jahren) wird, die tabelle gesplittet und fertig.

dank an alle für die unterstützung.

phil