v4 (random), v7 (zeitbasiert), v1, NIL — bis zu 1000 auf einmal
Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, der weltweit eindeutige Kennungen ohne zentrale Vergabestelle erzeugt. Sie ist in RFC 4122 (Klassik) und RFC 9562 (UUIDv6/7/8) standardisiert. Dargestellt als 32 Hexadezimalziffern in 5 durch Bindestriche getrennten Gruppen.
Bei UUIDv4 sind 122 von 128 Bits zufällig (die anderen 6 sind Version und Variante). Die Kollisionswahrscheinlichkeit ist astronomisch klein: Selbst bei einer Milliarde UUIDs pro Sekunde über 85 Jahre wäre die Wahrscheinlichkeit einer Kollision noch unter 50 %. Praktisch heißt das: UUIDs gelten als kollisionsfrei. Dieses Tool nutzt die Web Crypto API (crypto.getRandomValues) für kryptografisch starke Zufallszahlen.
Eine UUID besteht aus 128 Bit, traditionell als 32 Hex-Zeichen mit 4 Bindestrichen geschrieben — also 36 Zeichen Gesamtlänge. Die Felder sind time_low (8) - time_mid (4) - time_hi_and_version (4) - clock_seq (4) - node (12). Die Version steht im ersten Nibble der dritten Gruppe (Position 13), die Variant im ersten Nibble der vierten Gruppe (Position 17). Eine v4-UUID erkennt man am 4 an Position 13 und einem Wert in {8, 9, a, b} an Position 17.
Die Norm RFC 4122 von 2005 definierte die klassischen Versionen 1-5. RFC 9562 (Mai 2024) löste sie ab und führte v6, v7 und v8 als offizielle Standards ein. Davor existierten v6 und v7 nur als Industrie-Konventionen (z.B. ULID, KSUID, Snowflake). Die wichtigste Neuerung ist v7: 48 Bit Unix-Millisekunden als Präfix, dann 74 Bit Zufall — damit sind die UUIDs in der Generierungsreihenfolge sortierbar, was bei B-Tree-Indices in PostgreSQL oder MySQL einen drastischen Performance-Schub bringt.
Warum kein einfacher Auto-Increment-Integer? UUIDs ermöglichen client-seitige ID-Generierung (kein Round-Trip zur DB nötig), verhindern das Erraten von IDs (kein /api/order/1234 -> 1235) und sind eindeutig über Sharding-Grenzen oder verteilte Systeme hinweg. Die Kehrseite: 16 Byte statt 4 oder 8 Byte pro Index-Eintrag, schlechtere Cache-Lokalität bei v4 (zufällige Einfügungen verteilen sich über den ganzen Index), Lesbarkeit für Menschen. v7 mildert den Index-Nachteil deutlich.
Wie viele UUIDs muss man erzeugen, bevor eine Kollision wahrscheinlich wird? Mit der Geburtstags-Approximation gilt für eine 50%-Kollisionswahrscheinlichkeit grob:
n ≈ sqrt(2 * 2^B * ln(2))
wobei B = effektive Zufallsbits.
Version Zufallsbits 50%-Kollision nach
---------+-------------+----------------------
v4 122 ~2.7 * 10^18 UUIDs
v7 74 ~1.6 * 10^11 UUIDs (pro Millisekunde-Bucket)
v1 < 48 Sekunden bei viel Traffic
UUIDv4-Layout (Hex):
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
^ ^
Version Variant (y in {8,9,a,b})UUIDs sind das Standardwerkzeug, sobald eine ID außerhalb einer einzelnen Datenbankzeile lebt. Hier fünf typische Szenarien:
id UUID PRIMARY KEY DEFAULT gen_random_uuid(). Für Tabellen mit über 100 Millionen Zeilen v7 verwenden: die zeitliche Ordnung hält den B-Tree-Index kompakter und beschleunigt INSERTs um Faktor 2-5x gegenüber v4.Idempotency-Key Header für POST-Requests, damit ein Retry nach Timeout nicht zwei Zahlungen auslöst. UUIDv4 ist hier Industrie-Standard: der Client erzeugt einen Key wie 3f29c3e0-b5c1-4f1a-9d4d-7c5b21a4e2f0, der Server cached die Antwort 24 Stunden unter diesem Key.s3://bucket/uploads/8d3a9e7c-...-da12fb.pdf. Verhindert Kollisionen und macht öffentliche Links unratbar (Capability-URL-Pattern). Bei Bildern oft kombiniert mit Hash für Content-Addressing.X-Request-ID: ...) sind häufig UUIDv4. Ermöglicht, einen Request über 20 Microservices hinweg zu folgen.UUIDs sind nicht magisch. Drei häufige Fallen: (1) v4 als Primärschlüssel auf großen Tabellen — die zufällige Einfügereihenfolge zerschießt B-Tree-Index-Lokalität und Write-Ahead-Logs. Lösung: v7 oder ULID. (2) v1 in öffentlichen Systemen — die ersten 60 Bit kodieren einen Timestamp und Teile der MAC-Adresse, was Privacy-Probleme erzeugt (siehe "Cohen UUID"-Geschichte). (3) v4 für Sicherheits-Token ist OK (122 Bit Entropie sind genug), aber wenn der UUID-Generator nicht crypto.getRandomValues nutzt, sondern Math.random(), ist alles verloren. Prüfe vor dem Einsatz: erzeugt deine UUID-Library nachweislich kryptografisch sichere v4-IDs? Node.js crypto.randomUUID() ja, ältere Polyfills oft nein.
crypto.randomUUID() sicher und schnell?crypto.getRandomValues) angezapft.{8D3A9E7C-1F2B-4A5D-9E0F-DA12FB44A1C2}. Du kannst beide Formate über die Format-Option dieses Tools umschalten.BINARY(16). VARCHAR(36) braucht 36 Byte statt 16 — also 2.25x mehr Speicher, 2.25x mehr I/O, langsamere Index-Scans. Bei MySQL hilft UUID_TO_BIN(..., 1) zusätzlich, die UUID umzuordnen, damit der Timestamp am Anfang steht (Pseudo-v7). Bei v7 ist diese Umordnung schon nativ drin.