Spalteninhalt löschen

[dcst55]

Hallo zusammen,

macht es aus Performance Sicht etwas aus, in einer großen Tabelle Spalten ohne Inhalt zu löschen, statt mit einem Leerzeichen zu überschreiben?

Es handelt sich um eine InnoDB Tabelle und die zutreffenden Spalten sind varchar100, varchar250 und int(11)

Besten Dank im Voraus!

 

[akretschmer]

was willst Du löschen, wenn da kein Inhalt ist?

 

[akretschmer]

also, prinzipiell kannst Du, wenn da kein Inhalt ist, das mit NULL füllen. Ich kenne und nutze MySQL nicht, in PostgreSQL belegen Strings faktisch so viel Platz, wie sie lang sind, plus eine Längenangabe. Dürfte in MySQL und Derivaten ähnlich sein. Unter Umständen werden Strings komprimiert gespeichert, nennt sich TOAST. Aber das spielt hier keine Rolle, weil MySQL das natürlich nicht kann.

 

[ukulele]

Also NULL ist nicht existent, das macht am meisten Sinn oder die ganze Spalte verwerfen. Ein Leerzeichen im wörtlichen Sinne macht so gar keinen Sinn. Die Performance sollte sich faktisch in beiden Varianten gar nicht unterscheiden.

 

[dabadepdu]

Und int11 ist auch nicht so gut geeignet für ein Leerzeichen (keine Ahnung, wie mysql reagiert)

Ich würde jedenfalls nie Datenkonsistenz nach Performance behandeln, selbst wenn es schneller wäre, Leerzeichen zu speichern.

 

[dcst55]

also, prinzipiell kannst Du, wenn da kein Inhalt ist, das mit NULL füllen. Ich kenne und nutze MySQL nicht, in PostgreSQL belegen Strings faktisch so viel Platz, wie sie lang sind, plus eine Längenangabe. Dürfte in MySQL und Derivaten ähnlich sein. Unter Umständen werden Strings komprimiert gespeichert, nennt sich TOAST. Aber das spielt hier keine Rolle, weil MySQL das natürlich nicht kann.

Danke für deine ausführliche Antwort. Mir geht es nicht um den belegten Speicherplatz, uch wenn man den Punkt nicht unbeachtet lassen sollte! Aber in erster Linie wollte ich die Auswirkungen auf die Performance näher betrachten!

 

[dcst55]

Also NULL ist nicht existent, das macht am meisten Sinn oder die ganze Spalte verwerfen. Ein Leerzeichen im wörtlichen Sinne macht so gar keinen Sinn. Die Performance sollte sich faktisch in beiden Varianten gar nicht unterscheiden.

Die vermeintlich „leeren“ Zellen sind nicht alle in der selben Spalte, daher ist das etwas schwierig!
Aber genau die Aussage habe ich erwartet. Nämlich, dass es keine Auswirkungen auf die Performance hat, wenn die Zelle mit einem Leerzeichen oder NULL gefüllt ist.

 

[akretschmer]

Aber in erster Linie wollte ich die Auswirkungen auf die Performance näher betrachten!

wenn etwas weniger Platz belegt, ist es auch schneller von der Platte gesaugt und verdreckt weniger Cache und RAM. Damit wird es dann vermutlich eher schneller als langsammer werden.

 

[dcst55]

Ich würde jedenfalls nie Datenkonsistenz nach Performance behandeln[…]

Wie meinst du den Satz genau?

 

[dcst55]

wenn etwas weniger Platz belegt, ist es auch schneller von der Platte gesaugt und verdreckt weniger Cache und RAM. Damit wird es dann vermutlich eher schneller als langsammer werden.

Hmm… auch wieder logisch… vor allem wenn die Tabelle 50GB groß ist und in jedem Datensatz mindestens 2 Zellen „leer“ sind…

 

[akretschmer]

Wie meinst du den Satz genau?

Wenn Dir Performance so wichtig ist, dann verwende MySQL mit der Blackhole-Engine. Wenn Dir Deinen Daten wichtig sind, Du diese nicht verliren willst und Dich darauf verlassen willst, dann verwende kein MySQL.

 

[ukulele]

Also "leer" ist NULL, alles andere ist nicht leer. Sind Daten gespeichert, wie z.B. eine Zeichenkette mit 0 Zeichen oder einem Leerschritt oder einem netten Spruch "hier keine Daten", dann belegt das Speicherplatz - je nach Format der Spalte unterschiedlich viel. Wird das gelesen braucht es auch Performance. Der Unterschied dürfte kaum messbar sein aber ja, es gibt ihn.

 

[dabadepdu]

Ich würde jedenfalls nie Datenkonsistenz nach Performance behandeln

Wie meinst du den Satz genau?

Nie Datenkonsistenz nachrangig zur Performance behandeln.*
Eine DB Engine liefert einen Haufen tolle "Werkzeuge", um konsistente Daten zu gewährleisten, das ist das Wichtigste!
Performance kommt erst danach. Wenn auch da die Bordwerkzeuge (Indizierung, Indextypen, Partitionierung, Cluster .. ) alles nicht mehr reicht, wäre der nächste Schritt ggf. Denormalisierung unter Wahrung der Konsistenz versteht sich.

*Man kann sich vielleicht darüber streiten, ob ein Leerzeichen schon eine Inkonsistenz bedeutet.