Enum – Performance, Nutzen und Alternativen

Posted by in MySQL

Wie die meisten, die sich schon etwas mit MySQL beschäftigt haben wissen, gibt es den Datentyp Enum. Denen die es noch nicht wussten hier als kurze Erklärung: Enum ist ein MySQL spezischer Datentyp, welcher es erlaubt, dass nur bestimmte Werte in eine Spalte eingetragen werden dürfen. So kann man zum Beispiel für eine Spalte „Aktiv“ ein ENUM(‚ja‘, ’nein‘) definieren wo nur ein ‚ja‘ oder ein ’nein‘ eingetragen werden darf.

An sich also eine tolle Sache. Nur die Frage ist, ob das auch performant ist oder ob es bessere Alternativen gibt.

Ronald Bradford hat in seinem Blog bereits darüber sinniert: To enum or not to enum?

So ergeben sich drei Argumente dagegen:

  • Es ist kein SQL Standard und der Datentyp wird in anderen SQL-Datenbankensystemen teilweise anders behandelt oder implementiert
  • Es besteht eine sehr enge Abhängigkeit zwischen der Datenbank und den Daten und es ist schwer Änderungen durchzuführen
  • Die Behandlung von Gültigkeitsprüfungen der Daten sollte in der Anwendung geschehen

Ein großer Vorteil besteht aber darin, dass man in der Datenbank auch sofort sieht was drin steht. Weil die Alternativen sind, dass man es direkt als VARCHAR speichert. Dabei würden deutlich mehr Zeichen verbraucht, da ein ’nein‘ 4 Zeichen benötigt, das Mapping auf den internen Typ jedoch nur 1 Zeichen. Das stimmt so nicht ganz aber im Grundprinzip ist es so.
Eine andere Alternative wäre es ‚ja‘ mit 1 zu kodieren und ’nein‘ mit 2. Dann braucht man entweder eine zweite Tabelle in der steht, welcher Wert was bedeutet und diese müsste man dann joinen. Das kostet natürlich Ressourcen.

Der MySQL PerformanceBlog hat einmal die verschiedenen Möglichkeiten der Umsetzung in Bezug auf die SELECT-Geschwindigkeit überprüft. Dabei hat sich gezeigt, dass der reine SELECT zwischen der Umsetzung als VARCHAR und der als ENUM kaum Unterschiede hat, ENUM ist einen kleinen Tick langsamer dabei.

Also ist ENUM in der Tat eine sinnvolle Lösung, wenn man eine Liste von möglichen Werten hat. Bei größeren Datenbanken spart man einfach Platz im Gegensatz zur VARCHAR Lösung. Und im Gegensatz zur Kodierung als INT sieht man einfach sofort welcher Wert repräsentiert wird und welche Werte möglich sind.

Aktuell gibt noch einen kleinen Bug, welcher auftritt, wenn man ein ENUM als utf8 kodiert. Dabei wird die ENUM-Spalte um 10-20% langsamer, als wenn man sie als latin1 kodiert. Aber da man die möglichen Werte sicher sowieso im normalen Bereich der 26 lateinischen Buchstaben hält, kann man da auch ohne Probleme beim latin1 bleiben.