Datentypen unter der Lupe: Wie INT, VARCHAR & Co. deine Datenbank effizient machen

Stell dir vor, deine Datenbank ist wie ein großer Schrank voller Schubladen. Jede Schublade hat eine bestimmte Größe und ist für bestimmte Dinge gedacht: Kleine Accessoires passen in kleine Fächer, große Aktenordner brauchen große Schubladen. Wenn die Schubladen falsch gewählt sind, passen die Dinge nicht ordentlich hinein, und du verlierst Zeit beim Suchen. Genauso funktionieren Datentypen in SQL: Sie bestimmen, wie Informationen gespeichert, verarbeitet und abgefragt werden.

Die richtige Wahl der Datentypen ist entscheidend aus drei Gründen:

  • Speichereffizienz: Jeder Datentyp belegt Speicherplatz. Ein zu großer Typ verschwendet Ressourcen, ein zu kleiner Typ kann die Daten unbrauchbar machen.
  • Datenintegrität: Mit passenden Typen stellst du sicher, dass nur gültige Werte gespeichert werden. Ein INT verhindert zum Beispiel, dass versehentlich Text in einer Zahlenspalte landet.
  • Performance-Optimierung: Die Wahl des Typs beeinflusst Abfragen, Indizes und Joins. Effiziente Datentypen können die Performance deiner Datenbank deutlich verbessern.

Schon kleine Entscheidungen können große Auswirkungen haben. In diesem Artikel werfen wir einen genauen Blick auf gängige Problemtypen, die häufig zu Fehlern oder Performanceproblemen führen. Zum Beispiel: Wann ist VARCHAR die bessere Wahl gegenüber TEXT? Und warum kann ein zu großzügig gewählter INT-Typ die Geschwindigkeit bremsen?

Mit diesem Wissen bist du bereit, deine Tabellen von Anfang an sauber und effizient zu gestalten, bevor die ersten Daten einziehen.

SQL Datentypen

Numerische Typen: Präzision zählt

Ganzzahlen (INT-Familie)

Ganzzahlen sind die Grundlage vieler Datenbankspalten, von Benutzer-IDs bis hin zu Zählerwerten. MySQL bietet verschiedene Typen, die sich in Speicherbedarf und Wertebereich unterscheiden:

Typ Speicher Wertebereich (SIGNED)
TINYINT 1 Byte -128 bis 127
SMALLINT 2 Bytes -32.768 bis 32.767
INT 4 Bytes -2.147.483.648 bis 2.147.483.647
BIGINT 8 Bytes -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807

Praxis-Tipp: Ein größerer Typ wie BIGINT ist nicht automatisch besser. Wenn deine Werte nie über einige Millionen hinausgehen, verbraucht INT weniger Speicher und Indizes laufen schneller.

MySQL bietet manchmal die Schreibweise INT(11). Das hat nichts mit der Größe der Zahl zu tun, sondern ist nur ein Display-Format, das in modernen Versionen kaum noch relevant ist.

Dezimalzahlen

Für Zahlen mit Nachkommastellen gibt es zwei Hauptoptionen: DECIMAL und FLOAT/DOUBLE. Der Unterschied liegt in der Genauigkeit:

  • DECIMAL: Exakte Speicherung, ideal für Finanzdaten. Beispiel: DECIMAL(5,2) erlaubt Zahlen von 0.00 bis 999.99.
  • FLOAT/DOUBLE: Gleitkommazahlen, schneller, aber nicht exakt. Fehler bei Finanzberechnungen sind möglich.

Warnung: Verwende FLOAT nicht für Preise oder Geldbeträge – Rundungsfehler können sonst zu Problemen führen.

f

Zeichenketten: Mehr als nur Text

VARCHAR vs. CHAR

VARCHAR und CHAR speichern Zeichenketten, unterscheiden sich aber im Speicherverhalten. CHAR hat eine feste Länge, VARCHAR eine variable. Das bedeutet:

  • CHAR(n): Immer n Zeichen, aufgefüllt mit Leerzeichen. Gut für Codes fester Länge, z. B. ISO-Ländercodes.
  • VARCHAR(n): Speichert nur die tatsächliche Länge plus 1–2 Bytes für die Länge. Flexibel, ideal für Namen, E-Mail-Adressen oder Texte variabler Länge.

Praxis-Tipp: Nutze CHAR nur für feste Längen. VARCHAR ist in den meisten Fällen effizienter.

Historisch wurde oft VARCHAR(255) verwendet. Heute ist das nicht mehr die Grenze, sondern nur noch eine praktische Orientierung – wähle die Länge passend zum Anwendungsfall.

TEXT vs. VARCHAR

Für längere Texte gibt es den TEXT-Typ. Er kann viel Speicher aufnehmen, hat aber Einschränkungen:

  • TEXT-Spalten können nicht ohne Weiteres in Indexen verwendet werden.
  • WHERE-Klauseln auf TEXT können langsamer sein, da MySQL keine Volltextindizes standardmäßig nutzt.

Entscheidungsbaum: Nutze VARCHAR, wenn die Länge überschaubar ist und du Filter oder Indizes benötigst. TEXT eignet sich für sehr lange Inhalte, wie Blogartikel oder Beschreibungen, die nicht oft in WHERE-Bedingungen vorkommen.

Zeitstempel: Der DATE/DATETIME-Dschungel

DATE vs. DATETIME vs. TIMESTAMP

Zeiten und Daten richtig zu speichern ist entscheidend, gerade wenn du Abfragen nach Zeiträumen oder historische Daten benötigst. Die gängigsten Typen sind:

  • DATE: Speichert nur das Datum im Format YYYY-MM-DD. Ideal für Geburtstage, Feiertage oder andere reine Datumsangaben.
  • DATETIME: Speichert Datum und Uhrzeit im Format YYYY-MM-DD HH:MM:SS. Keine automatische Zeitzonenanpassung.
  • TIMESTAMP: Speichert Datum und Uhrzeit und konvertiert automatisch in UTC. Praktisch für Log-Zeitpunkte, die auf verschiedenen Servern konsistent bleiben müssen.

Timezones und TIMESTAMP WITH TIME ZONE

Bei verteilten Systemen kann die Zeitzone problematisch werden. MySQL unterstützt TIMESTAMP, der intern UTC speichert und beim Abruf in die lokale Zeitzone konvertiert. DATETIME hingegen speichert unverändert – hier musst du die Zeitzone selbst berücksichtigen.

Formatierungs-Tipp

Nutze möglichst das ISO-8601-Format (YYYY-MM-DD HH:MM:SS). So verhinderst du Missverständnisse bei internationalen Daten und Abfragen.

Beispiel: BETWEEN-Fehler

Ein häufiger Fehler: WHERE created_at BETWEEN '2025-08-01' AND '2025-08-31'. DATETIME enthält auch Stunden, Minuten und Sekunden, sodass die Abfrage Einträge am 31.08. nach 00:00 ausschließt. Besser ist:

WHERE created_at >= '2025-08-01 00:00:00'
  AND created_at <= '2025-08-31 23:59:59'

Spezialisten: BOOLEAN, ENUM & Co.

BOOLEAN

Der Datentyp BOOLEAN existiert in MySQL meist nur als Alias für TINYINT(1). Intern wird also eine 0 für false und eine 1 für true gespeichert. Vorteil: Klar verständlich im Code und in Abfragen.

ENUM

ENUM ist ein Datentyp für eine feste Liste an möglichen Werten, z. B. ENUM('klein','mittel','groß'). Vorteile:

  • Speicherplatzsparend
  • Datenintegrität: Nur definierte Werte erlaubt

Nachteile:

  • Schwieriger zu erweitern
  • Bei Änderungen muss die Tabelle angepasst werden

Alternative: Lookup-Tabellen, die flexibler und relationaler sind.

JSON / XML

Strukturierte Datentypen wie JSON oder XML speichern komplexe Daten direkt in einer Spalte. Ideal, wenn du flexible Strukturen brauchst, z. B. für Metadaten oder Konfigurationen. Nachteil: Schwer zu indexieren, Abfragen können langsamer sein.

Entscheidungshilfe: Welcher Typ wofür?

Die Wahl des richtigen Datentyps hängt stark vom Anwendungsfall ab. Die folgende Entscheidungsmatrix gibt dir einen schnellen Überblick:

Anwendungsfall Empfohlener Typ
User-ID BIGINT (auto_increment)
E-Mail VARCHAR(254)
Preis DECIMAL(10,2)
Log-Zeitpunkt DATETIME(6)
Feature-Flags BOOLEAN

Worst Practices: Typen-Fehler vermeiden

  • VARCHAR zu großzügig wählen – unnötig großer Speicherverbrauch
  • TEXT für kurze Strings – Performanceverlust bei Filtern und Indizes
  • FLOAT für Finanzdaten – Rundungsfehler
  • DATETIME ohne Zeitzonen im verteilten System
  • Unterschiedliche Typen bei Joins – langsame Abfragen
  • ENUM überladen – schwer wartbar
  • BOOLEAN als INT speichern, wenn es eigentlich TRUE/FALSE sein soll
  • Zu kleine INT-Typen für wachsende IDs
  • Verzicht auf DECIMAL, wenn exakte Werte erforderlich sind
  • Keine Länge für VARCHAR definieren – Unsicherheit bei Speicher und Indizes

Performance-Crashkurs

Falsche Typen killen Indizes

Indizes sind das Herzstück für schnelle Abfragen. Wenn die Spaltentypen nicht optimal gewählt sind, wirken Indizes kaum. Beispiele:

  • Unterschiedliche Typen in Join-Bedingungen: INT vs. BIGINT – der Index wird nicht effizient genutzt.
  • TEXT-Spalten in WHERE-Bedingungen – Index nur eingeschränkt nutzbar, Abfragen werden langsamer.

Speicherplatzvergleich

Bei großen Datenmengen wirkt sich der Typ stark aus:

  • INT benötigt 4 Bytes pro Wert, VARCHAR(20) kann bei 1 Million Zeilen deutlich mehr Speicher beanspruchen, besonders wenn die Strings nahe an 20 Zeichen sind.
  • Weniger Speicher = kleinere Indexgrößen = schnellere Abfragen.

Join-Performance

Gleiche Datentypen in Join-Bedingungen sind Pflicht. MySQL muss sonst Typkonvertierungen durchführen, was die Performance massiv verschlechtert:

SELECT *
FROM users u
JOIN orders o ON u.id = o.user_id;

Beide Spalten sollten denselben Typ haben, z. B. BIGINT.

FAQ zu Datentypen

Wann nehme ich DECIMAL statt FLOAT?

DECIMAL speichert Zahlen exakt, FLOAT/DOUBLE nur ungefähr. Für Finanzdaten, Preise oder alles, wo Rundungsfehler problematisch sind, immer DECIMAL verwenden.

Warum soll ich VARCHAR(1000) nicht blind nutzen?

Zu große VARCHAR-Längen verschwenden Speicher und können Indizes vergrößern. Wähle die Länge passend zu deinem Anwendungsfall, z. B. VARCHAR(254) für E-Mail-Adressen.

TIMESTAMP vs. DATETIME in MySQL 8.0?

  • TIMESTAMP: Automatische UTC-Konvertierung, ideal für Logs, aber maximalwert begrenzt (2038-01-19).
  • DATETIME: Speichert Datum und Uhrzeit ohne Zeitzonen-Umrechnung, größere Flexibilität, keine 2038-Grenze.

SQL Datentypen Cheat Sheet

Fazit

Datentypen sind die Basis für effiziente, performante und fehlerfreie Datenbanken. Die wichtigsten Learnings:

  • So spezifisch wie nötig, nicht so komplex wie möglich: Wähle den Datentyp passend zum Anwendungsfall.
  • Performance beginnt bei der Spaltendefinition: Kleine, passende Typen sparen Speicher und beschleunigen Abfragen.
  • Datenintegrität > Bequemlichkeit: Richtige Typen verhindern fehlerhafte Daten und vereinfachen Wartung.

Gut gewählte Datentypen bilden das Fundament für stabile, schnelle und langfristig wartbare Datenbanken.

SQL Datentypen Cheat Sheet

Lade dir jetzt unser kompaktes SQL Datentypen Cheat Sheet als PDF herunter und behalte alle wichtigen Datentypen auf einen Blick: SQL Datentypen Cheat Sheet (PDF)

Perfekt zum schnellen Nachschlagen, für den Alltag im SQL-Training oder beim Erstellen von Tabellen.
Von numerischen Typen über Zeichenketten bis zu Datum/Zeit und Boolean – alles übersichtlich in einer praktischen Übersicht.