Wie kann ich auslesen wieviel speicher eine Zeile belegt?

[Lennynero]

Hallo Miteinander,

hier ein kurzes Update: nach einem kurezn hin- und her mit dem Support von Navicat (denn nach einer Weile testen stellte sich heraus, dass der Fehler nur dort auftrat) und dem einschalten des Logging war mir aufgefallen, das Navicat (wenn man das Queryfenster nutzt) mit jeder Query auch ein "SET PROFILING=1" abfeuerte (nutzt man die Konsole oder den Tabelleneditor ist das nicht der Fall!).

Eine Kombinierte Abfrage auf der Shell ("SET PROFILING=1; ALTER .....") führte dann auch zum gleichen Ergebnis: die Daten wurden zerrissen.

Die Bugmeldung bei MySQL hat mittlerweile auch den Status "verified".

Für uns hier ist die Lösung erstmal das deaktivieren des "SHOW PROFILING" innerhalb von Navicat, in der Hoffnung, dass der Bug auch irgendwann behoben werden kann.


Danke nochmal für die Tipps!

Gruss,
Lenny

[Lennynero]

Nein, keine #sql oder #.sql oder vergleichebare Sachen.

Auch in den Information Schemata finde ich keine Hinweise.

[onemorenerd]

Schon mal ein SHOW TABLES gemacht? Tauchen da Tabellen mit dem Präfix #sql oder #.sql auf?

[Lennynero]

Hilft es, wenn man vor dem ALTER TABLE einen Daten-Dump zieht und den nachher wieder drüberspielt? Meine Vermutung geht dahin, dass beim ALTER TABLE die Beziehung zwischen der Haupt- und der Zusatztabelle verloren geht und daher die Daten abgeschnitten werden.

Ja, zumindest würde es das verhalten erklären... zumindest zum Teil. Das nicht alle Zeilen betroffen sind.... hinterlässt halt irgendwie eine Erklärungslücke (ich hatte auch die Daten schon verglichen, in der Hoffnung das es vielleicht auch etwas mit dem Änderungsdatum zu tun haben könnte, aber auch da ist die Mischung "betroffener" "nicht betroffener" Zeilen kunterbunt.

Wenn ich die Daten vor dem ALTER dumpe und danach in eine (korrupte) Tabelle zurückspiele, stimmen die Werte übrigens.

Von da aus wird wohl wirklich "einfach" ein Teil der Zuordnung zwischen der versteckten und der eigentlichen Tabelle zerstört. Kann es sein das ggf. sogar mehrere versteckte Tabellen angelegt werden?

[AmicaNoctis]

Hilft es, wenn man vor dem ALTER TABLE einen Daten-Dump zieht und den nachher wieder drüberspielt? Meine Vermutung geht dahin, dass beim ALTER TABLE die Beziehung zwischen der Haupt- und der Zusatztabelle verloren geht und daher die Daten abgeschnitten werden.

[onemorenerd]

Dieses Zitat liefert zwar eine Erklärung für deine Beobachtung, aber keine Lösung.
Jetzt wissen wir, dass die NDBCluster-Engine die Daten ab dem 257. Byte in eine versteckte Tabelle kippt. Aber sie muss beim Zugriff auf die Haupttabelle die Daten wieder zusammensetzen. Das macht sie bei dir scheinbar nicht und mir fällt noch nichts ein, wie man diesem Fehler beikommen kann.

Du hast offenbar ein Ticket dazu erstellt. Warten wir einfach ab, was die Profis dazu sagen.

[Lennynero]

Sorry, ich hab dich misverstanden. Du hast kein Problem mit VARCHAR- sondern mit TEXT-Spalten.

Ich hab im Manual gewühlt und folgendes gefunden:

Thx. (ich müsste erst noch ein paar andere User bewerten, bevor ich dich wieder bewerten kann).

Das mit den 256 Zeichen scheint da ja sehr gut zu passen, nun muss ich noch herausfinden wieso die nur bei einigen Zeilen abgeschnitten werden (ein Oberflächlicher Vergleich von betroffenen und nicht betroffenen Zeilen offenbart mir zumindest keinen Hinweis).

MIt dem "reproduzierbarem Fehler" war ich dagegen zu voreilig: in etwa 50% der Tests wurde Text abgeschnitten, in anderen Fällen nicht.

[onemorenerd]

Sorry, ich hab dich misverstanden. Du hast kein Problem mit VARCHAR- sondern mit TEXT-Spalten.

Ich hab im Manual gewühlt und folgendes gefunden:

Quelle: MySQL :: MySQL 5.1 Reference Manual :: 10.5 Data Type Storage Requirements
TEXT and BLOB columns are implemented differently in the NDB Cluster storage engine, wherein each row in a TEXT column is made up of two separate parts. One of these is of fixed size (256 bytes), and is actually stored in the original table. The other consists of any data in excess of 256 bytes, which is stored in a hidden table. The rows in this second table are always 2,000 bytes long. This means that the size of a TEXT column is 256 if size <= 256 (where size represents the size of the row); otherwise, the size is 256 + size + (2000 – (size – 256) % 2000).

MySQL :: MySQL 5.1 Reference Manual :: 17.4.21 ndb_size.pl ? NDBCLUSTER Size Requirement Estimator

[Lennynero]

Die Felder waren weder vorher noch nachher VARCHAR Felder, sondern sind in allen Sicherung als Text-Felder definiert (und sind auch in der fehlerhaften Variante immer noch als Text-Felder definiert).

Was die Sache mit dem ALTER Befehl betriff: es ist reproduzierbar, d.h. ausgeführt auf dem "sauberen" Datenbestand werden einige (nicht alle) der Textfelder auf 256 Zeichen gekürzt.

Die Änderung des ENUM_Feldes mit Navicat (über Tabelle bearbeiten) oder dem MySQL Query Browser führt interessanterweise nicht zu diesem verhalten.

Es ist auch unerheblich ob ich dem ALTER Statement ein "DEFAULT NULL" oder nicht mitgebe.

Serverversion ist: 5.1.30-ndb-6.3.20, Tabellentyp (wie bereits erwähnt) ndbcluster.

[onemorenerd]

Achja, das hab ich vergessen zu erwähnen: Es gibt keine solche Funktion. Deshalb habe ich den "Umweg" gezeigt.

Ich bezweifle übrigens, dass o.g. ALTER-Statement die VARCHAR-Spalten in irgendeiner Form beeinflusst hat. Damit wurde schließlich nur deine ENUM-Spalte geändert. Die Textspalten waren vorher schon VARCHAR(255) und damit unmöglich länger als 255 Zeichen.
Zwar kann VARCHAR ab 5.0.3 bis 2^16 Zeichen lang sein, aber wenn man eine Spalte als VARCHAR(255) definiert, werden die Daten auf diese Länge beschnitten. Das geschieht schon beim Einfügen, nicht erst beim nächsten ALTER.

[Lennynero]

Dort wo du diese Aussage aufgeschnappt hast, steht bestimmt, dass es nicht immer sinnvoll oder machbar ist, bis zur 5NF zu normalisieren. Aber 3NF oder BCNF darf es schon sein und das bringt in der Praxis auch keine Nachteile.

Abhängig vom Verwendungszweck ist es nicht zwingend notwendig, aber letzten Endes ist das hier vorliegende DB-Design ja nicht wirklich neu und vor allem gewachsen, ein Relaunch steht wie erwähnt sowieso bevor. Von da aus ist es auch nicht meine Absicht über das Tabellendesign zu diskutieren, vielmehr habe ich anfangs eine recht klare Frage gestellt:

Hi,

gibt es einen MySQL Befehl, mit dem ich auslesen kann wieviel Speicher eine Zeile belegt?

So etwa:

SELECT Memory(), id FROM table

Gruss,
Markus

bekomme eine Belehrung über DB-Design und

Dann hast du vermutlich die Gesamtspeicherbreite eines Datensatzes überschritten, was bei so vielen Spalten kein Wunder ist.

Onemorenerds Antwort ging ja schon in die Richtung und auch eine Antwort: es gibt keine entsprechende Funktion wäre ja schon okay.

EDIT: Bzgl. ENUM vs. JOIN:
http://www.mysqlperformanceblog.com/...hat-is-faster/
http://stackoverflow.com/questions/3...vs-join-tables

[AmicaNoctis]

Die Praxis zeigt durchaus, das nicht immer "normalisieren" der zwingend beste Weg ist.

Dort wo du diese Aussage aufgeschnappt hast, steht bestimmt, dass es nicht immer sinnvoll oder machbar ist, bis zur 5NF zu normalisieren. Aber 3NF oder BCNF darf es schon sein und das bringt in der Praxis auch keine Nachteile.

[Lennynero]

Dann hast du vermutlich die Gesamtspeicherbreite eines Datensatzes überschritten, was bei so vielen Spalten kein Wunder ist.

Genau das vermute ich auch, deshalb auch die Frage nach der Möglichkeit die Gesamtspeicherbreite der Tupel zu ermitteln.

[Lennynero]

Das Datenbankdesign ist doch ziemlicher Schrott. Am besten alles niederreißen und vernünftig aufbauen.

Normalisierung (Datenbank) ? Wikipedia

Die Praxis zeigt durchaus, das nicht immer "normalisieren" der zwingend beste Weg ist.

Nebenbei finde ich es beachtlich, das du in der Lage bist Aufgrund des Layoutes einer Tabelle auf das Design der ganzen Datenbank zu interpolieren. Sicherlich könnte man einige (wenn nicht sogar alle) ENUM und SET Felder durch weitere Tabellen abbilden, das würde aber jetzt einen Rattenschwanz an arbeit nach sich ziehen, der aber überflüssig ist da wir sowieso schon an der nächsten Version arbeiten. Mein Problem besteht aber jetzt und bis die nächte Version läuft wird es noch ein paar Wochen evt. sogar Monate dauern.

Es ist ja auch so, das man in die entsprechenden Spalten auch wieder Texte die länger als 256 Zeichen sind schreiben kann und es ist ja nicht jede Zeile betroffen gewesen.

Danke für deine Belehrung.

[AmicaNoctis]

Dann hast du vermutlich die Gesamtspeicherbreite eines Datensatzes überschritten, was bei so vielen Spalten kein Wunder ist.