Die Struktur einer UUID v4: 122 Bit Zufall im 36-Zeichen-Format
Eine UUID v4 ist kein beliebiger 36-Zeichen-String – sie folgt einem festen Schema, das durch RFC 4122 definiert wird. Von den 128 Bit einer UUID sind genau 122 Bit reiner Zufall. Die restlichen sechs Bit sind festgelegt: Vier Bit kennzeichnen die Version (hier 0100 für v4) und zwei Bit den Variantentyp (meist 10 für den standardkonformen Variant nach RFC 4122). Das ergibt das bekannte Erscheinungsbild, in dem die Ziffern an bestimmten Positionen immer gleich sind.
Ein konkretes Beispiel: f47ac10b-58cc-4372-a567-0e02b2c3d479. Die dritte Gruppe beginnt mit einer 4 (Version), die vierte Gruppe mit a, b, 8 oder 9 (Variant). Die restlichen 32 Zeichen können jeden Hexadezimalwert annehmen. Wenn Sie die Option Bindestriche entfernen aktivieren, erhalten Sie einen 32-stelligen Hex-String – die Zeichenanzahl sinkt von 36 auf 32, aber der Zufallsgehalt bleibt unverändert.
Die Anzeige in Großbuchstaben ändert ebenfalls nur die optische Darstellung: A–F statt a–f. Der zugrundeliegende Wert bleibt derselbe, aber manche Systeme (z. B. bestimmte Datenbank-Exporte oder Log-Formate) erwarten Großschreibung für bessere Lesbarkeit. Unser Generator respektiert diesen Formatierungswunsch sofort bei jeder Änderung.
Kollisionswahrscheinlichkeit und die Macht der 122 Bit
Wenn Sie 122 Bit reiner Zufall in einer UUID v4 versammeln, liegt die Wahrscheinlichkeit einer Kollision in praktischen Szenarien nahe null. Rechnen wir: Die Anzahl möglicher UUID v4 beträgt (2^‹122›). Das ist eine unvorstellbar große Zahl – etwa 5,3 Dezillionen (5,3·10³⁶). Selbst wenn Sie eine Milliarde UUIDs pro Sekunde generieren, bräuchten Sie zig Milliarden Jahre, um auch nur einen nennenswerten Bruchteil des Raums abzudecken.
Für den praktischen Einsatz in verteilten Systemen heißt das: Sie können UUID v4 ohne Koordinationsaufwand in verschiedenen Knoten erzeugen, ohne eine zentrale Vergabestelle zu benötigen. Auch Offline-Szenarien, etwa in einer natives App ohne Internetverbindung, sind unkritisch. Der Generator auf unserer Seite nutzt crypto.randomUUID oder eine gleichwertige Browser-API – dieselbe Quelle, die auch für kryptografische Schlüssel verwendet wird. Die IDs entstehen lokal im Browser, kein Datenverkehr zu einem Server, kein Tracking.
Ein häufiger Irrtum: Manche Entwickler glauben, UUID v4 enthalte eine Zeitkomponente wie UUID v1. Das stimmt nicht. Der Zeitstempel in v1 oder v7 ist hier bewusst nicht vorhanden. Wenn Sie also nachvollziehen möchten, wann eine ID erzeugt wurde, müssen Sie einen separaten Zeitstempel speichern.
Auswirkung auf Datenbankindizes: Fragmentierung und Performance
Der größte praktische Unterschied zwischen UUID v4 und zeitbasierten IDs (UUID v7, Snowflake, ULID) zeigt sich in der Leistung von B‑Tree-Indizes. Ein B‑Tree ist ein balancierter Baum, der sortierte Einfügungen optimal handhabt – neue Werte landen meist auf der gleichen Seite, Caches bleiben warm, Seitenaufteilungen sind selten.
UUID v4 ist per Definition nicht sortiert. Jeder neue Wert kann an einer beliebigen Stelle im Wertebereich liegen. Die Folge: Eine Einfügung in einen indexierten Primärschlüssel führt häufig zu einer Seitenaufteilung (page split), weil der Datenbank-Engine nicht ausreicht, die vorhandenen Seiten zu füllen. Bei hohen Schreibvolumen steigen die I/O-Kosten deutlich, der Buffer-Pool wird fragmentiert, und die Schreibleistung sinkt.
In Benchmarks sieht man oft einen Faktor 3 bis 10 Unterschied zwischen sequenziellen IDs und UUID v4 bei massivem Einfügen. Dagegen helfen nur zwei Strategien: (1) auf ein zeitbasiertes Format wie UUID v7 umsteigen oder (2) die Index-Fragmentierung durch regelmäßige Reorganisation bekämpfen. Unser Tool bietet deshalb im Dropdown auch UUID v7 und ULID an – für Anwender, die die Vorteile der Lesbarkeit einer UUID brauchen, aber die Indexperformance verbessern möchten.
Für Datenbankdesigner, die bewusst auf UUID v4 setzen, etwa um Enumeration von Datensätzen zu verhindern, ist dieser Performance-Nachteil oft akzeptabel. Die Transparenz über den Trade‑Off ist entscheidend.
Vergleich mit zeitbasierten Alternativen (UUID v7, ULID)
Die Wahl des ID-Formats hängt vom Anwendungsfall ab. Alle gängigen Formate auf unserer Seite haben unterschiedliche Eigenschaften:
| Eigenschaft | UUID v4 | UUID v7 | ULID |
|---|---|---|---|
| Zufallsbits | 122 | 62 | 80 (in 128 Bit) |
| Zeitstempel | nein | ja (Millisekunden) | ja (Millisekunden) |
| Sortierung | arbiträr | aufsteigend | aufsteigend |
| Länge (Standard) | 36 Zeichen | 36 Zeichen | 26 Zeichen (Crockford) |
| Besonderheit | höchste Entropie | B-Tree-freundlich | URL-sicherer Bas32 |
UUID v7 komprimiert einen 48-Bit-Zeitstempel in die ersten 12 Zeichen, gefolgt von 62 Bit Zufall und den obligatorischen Version-/Variant-Bits. Die IDs sind aufsteigend sortiert, aber nicht streng monoton bei mehr als einer ID pro Millisekunde. ULID bietet ähnliches in kürzerer, gut lesbarer Form – 26 Zeichen, ohne Bindestriche und mit Basis-32-Codierung.
Wann also UUID v4? Wenn Sie absolute Unvorhersagbarkeit benötigen (etwa für API-Tokens, Sitzungs-IDs oder geheime Ressourcen-IDs) und die Index-Kosten in Kauf nehmen. Wann zu UUID v7 wechseln? Sobald der Primärschlüssel einer hochfrequent geschriebenen Tabelle die Datenbankleistung beeinträchtigt.
Anwendungsfälle für nicht-sequenzielle IDs
Warum überhaupt auf eine zufällige ID setzen? Drei klassische Szenarien:
-
Sicherheit durch Verhinderung von Enumeration – Wenn Sie Datensätze, Benutzer oder Ressourcen nummerieren (1,2,3…), kann jeder Angreifer die Gesamtzahl erraten und durch einfaches Inkrementieren auf geschützte Daten zugreifen. UUID v4 verbirgt diese Information.
-
Verteilte Systeme ohne zentrale Koordination – Jeder Knoten kann lokal IDs erzeugen, ohne mit einer Datenbank oder einem globalen Sequencer zu kommunizieren. Das reduziert Latenz und Single-Point-of-Failure-Risiko.
-
Offline-Generierung – In mobilen Apps oder Edge-Geräten, die später mit einem Backend synchronisieren, müssen IDs schon vor dem ersten Netzwerkkontakt eindeutig sein. UUID v4 erfüllt diese Anforderung.
Entwickler testen oft Mischsysteme: Sie verwenden UUID v4 im öffentlichen Interface (API, URL-Pfade) und intern eine aufsteigende ID als Primärschlüssel. Aber auch das birgt Risiken, wenn die öffentliche UUID in einer anderen Tabelle referenziert wird – dann lebt der Index-Fragmentierungsnachteil trotzdem weiter.
Format-Anpassungen: Wann Großbuchstaben und wann ohne Bindestriche?
Die Optionen Uppercase und Include hyphens sind nicht nur kosmetisch. Sie beeinflussen die Interoperabilität:
-
Ohne Bindestriche: Die ID wird auf 32 Zeichen verkürzt. Ideal für URL-Parameter, Benutzernamen oder Spalten, die nur Hexadezimal erlauben. Manche Datenbanktreiber erwarten den String ohne Trennzeichen. Achtung: Die Lesbarkeit leidet; Menschen können die Gruppierung nicht mehr intuitiv erfassen.
-
Mit Großbuchstaben: Systeme wie AWS (S3-Bucket-Namen, ARN) oder einige MongoDB-Konfigurationen behandeln
Aundaals gleichwertig. Wenn Sie jedoch eine 1:1-Repräsentation in einem Token erwarten (z. B. für OAuth-Client-Secrets), kann die Großschreibung zu Verwirrung führen, falls Client und Server unterschiedliche Konventionen haben. Unser Tool schaltet beide Optionen sofort um, sodass Sie das Ergebnis in Echtzeit sehen und per Mausklick oder „Alle kopieren“ in die Zwischenablage übernehmen.
Ein typischer Workflow: Sie generieren 50 UUIDs mit Großbuchstaben und Bindestrichen für ein Datenlast-Testskript. Dann deaktivieren Sie die Hyphen für eine URL-kompatible Version. Beide Kopiervorgänge (einzeln oder gesamt) funktionieren direkt aus der Liste.
Browser-seitige Generierung ohne Serverlast
Alle IDs auf dieser Seite entstehen ausschließlich im Browser. Dazu nutzen wir die crypto.getRandomValues()-API (oder crypto.randomUUID(), falls der Browser sie unterstützt). Der Vorteil: Es gibt keinerlei Netzwerklatenz, keine Serverkosten, kein Logging der erzeugten Werte. Der Status „Ready.“ oder „Generated.“ zeigt an, dass die Engine bereit ist; nach dem Kopieren erscheint „Copied all!“ oder der geklickte einzelne UUID wird in die Zwischenablage geschrieben.
Diese Architektur ist nicht nur privat, sondern auch blitzschnell: Selbst 100 UUIDs sind in Millisekunden erzeugt. Einzige Einschränkung: Die Zufallsquelle ist so gut wie die des Betriebssystems – und das ist bei modernen Browsern auf dem Niveau von kryptografischen Schlüsseln. Für Testdaten völlig ausreichend, für hochsensible Geheimnisse sollte man aber ein spezialisiertes Token-Management erwägen.
FAQ
Wie hoch ist die Wahrscheinlichkeit einer Kollision bei UUID v4? Praktisch null. Bei (2^‹122›) möglichen Werten liegt die Kollisionswahrscheinlichkeit selbst bei einer Milliarde existierender IDs unter (10^‹-18›). Erst ab etwa (2^‹61›) IDs steigt die Wahrscheinlichkeit auf 50 % an – das sind mehr als eine Trillionen IDs.
Kann ich UUID v4 als Primärschlüssel in einer MySQL-Datenbank verwenden? Technisch ja, aber bedenken Sie die Index-Fragmentierung. Bei InnoDB kann die Schreibleistung um Faktor 3–10 sinken im Vergleich zu AUTO_INCREMENT. Nutzen Sie lieber UUID v7 oder setzen Sie auf eine spezielle Index-Reorganisation.
Was ist der Unterschied zwischen UUID v4 und UUID v7? UUID v4 ist komplett zufällig (122 Bit), UUID v7 beginnt mit einem 48-Bit-Zeitstempel. v7 ist sortiert (B-Tree-freundlich), während v4 keine Ordnung liefert.
Warum kann ich bei UUID v4 die Großschreibung ändern? Manche APIs, Datenbanken oder Log-Formate erwarten durchgängig Großbuchstaben für Hexadezimalwerte. Die Änderung hat keinen Einfluss auf die Eindeutigkeit – es ist nur eine Frage der Darstellung.
Wie wird die Zufallszahl im Browser erzeugt?
Über crypto.getRandomValues() oder crypto.randomUUID(). Beide APIs greifen auf betriebssystemnahe Zufallsquellen zurück (z. B. /dev/urandom unter Linux, CryptGenRandom unter Windows). Kein Server ist involviert.
Sollte ich Bindestriche entfernen? Wenn Sie die ID in URLs oder kurze Token einbetten möchten, ist eine 32-stellige Hex-Zeichenkette oft praktischer. Für die Lesbarkeit und Standardkonformität empfehlen wir, die Bindestriche zu belassen – sie sind Teil des RFC-Formats.