MT
My Toolbox

UUID-Generator: UUID v4 und v7 online generieren

Kryptographisch zufällige UUIDs sofort generieren. Unterstützt v4 (zufällig) und v7 (zeitlich sortierbar, RFC 9562). Einzeln oder bis zu 100 auf einmal. Verwendet crypto.randomUUID(), dein Browser erledigt die Arbeit, nichts erreicht einen Server.

Eindeutige UUIDs generieren
Generieren Sie schnell eindeutige Kennungen

UUID v4 (Random)

Generated using random numbers. No structure, completely random. Suitable for most use cases.

UUID v7 (Time-based)

Generated using a timestamp and random numbers. Sortable by time, improving database performance.

UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.

UUID-Versionen erklärt

Eine UUID ist ein 128-Bit-Bezeichner, formatiert als 32 Hexadezimalziffern in 5 Gruppen: 550e8400-e29b-41d4-a716-446655440000. Die Versionsnummer steht im 13. Zeichen (die "4" in diesem Beispiel bedeutet v4).

UUID v4 ist reiner Zufall: 122 Zufallsbits mit 6 Bits für Versions- und Variantenmarker reserviert. Die Kollisionswahrscheinlichkeit ist astronomisch gering. Du müsstest 2,71 x 10^18 UUIDs generieren, um eine 50%ige Chance auf ein Duplikat zu haben. In der Praxis heißt das "nie".

UUID v7 (definiert in RFC 9562, veröffentlicht 2024) ist der Neuling. Sie setzt einen Unix-Zeitstempel in die ersten 48 Bits, gefolgt von Zufallsbits. Das bedeutet: v7-UUIDs lassen sich chronologisch sortieren. Das ist ein großer Gewinn für Datenbankindizes. PostgreSQL und MySQL leiden beide unter zufälligen v4-UUIDs als Primärschlüssel, weil B-Baum-Indizes bei zufälligen Einfügungen schlecht fragmentieren. v7 behebt das, indem Einfügungen immer am Ende des Indexes landen.

Wann was verwenden: v4 für alles, bei dem die Reihenfolge keine Rolle spielt (Sitzungs-Token, Korrelations-IDs, Idempotenz-Schlüssel). v7 für Datenbank-Primärschlüssel, Ereignis-IDs oder alles, was nach Erstellungszeit sortiert wird. Für neue Projekte in 2024+ ist v7 der bessere Standard.

Anleitung

  1. UUID-Version wählen: v4 (zufällig) oder v7 (zeitlich sortierbar).
  2. Anzahl festlegen: 1 für schnelles Greifen, bis zu 100 für Massenbedarf.
  3. Generieren klicken. Ergebnisse erscheinen sofort.
  4. Einzelne UUIDs oder alle auf einmal kopieren. Kleinbuchstaben mit Bindestrichen, bereit zum Einfügen.

Wann du das brauchst

Datenbank-Primärschlüssel in verteilten Systemen

Auto-Inkrement-IDs funktionieren nicht bei mehreren Schreibknoten. UUIDs lassen jeden Knoten unabhängig IDs erzeugen, ohne Koordination. v7 verwenden wenn chronologische Reihenfolge nötig (meistens), v4 wenn IDs explizit nicht die Erstellungsreihenfolge verraten sollen.

API-Idempotenzschlüssel

Stripe, AWS und die meisten Zahlungs-APIs erfordern einen Idempotenzschlüssel gegen doppelte Gebühren. Pro Anfrage eine v4 UUID generieren. Wenn die Anfrage fehlschlägt und mit demselben Schlüssel wiederholt wird, weiß der Server, dass es ein Wiederholungsversuch ist.

Datei- und Objektbenennung im Cloud-Speicher

Benutzerdateien auf S3 hochladen? UUID als Objektschlüssel verwenden. Keine Kollisionen, kein Bereinigen von Dateinamen nötig, keine Informationslecks über Upload-Reihenfolge (mit v4) oder einfache chronologische Auflistung (mit v7).

Korrelations-IDs für verteiltes Tracing

Am Eingangspunkt einer Anfrage eine UUID generieren und über Header an alle Microservices weiterleiten. Wenn etwas kaputt geht, alle Logs nach dieser UUID durchsuchen, um den vollständigen Anfragepfad zu sehen.

Wissenswertes

1.

v4 UUIDs sind als Datenbank-Primärschlüssel schlecht

Zufällige v4-UUIDs führen zu B-Baum-Index-Fragmentierung, da Einfügungen an zufälligen Positionen landen. Mehr Seitenteilungen, mehr Festplatten-I/O, langsamere Schreibvorgänge. Benchmarks zeigen 2-3x bessere Insert-Performance mit v7 in PostgreSQL. Für neue Tabellen v7 nehmen.

2.

UUIDs sind keine Geheimnisse

Eine UUID ist ein Identifikator, kein Sicherheits-Token. v7 UUIDs verraten die Erstellungszeit (Zeitstempel in den ersten 48 Bits). v4 UUIDs sind zufällig, haben aber nur 122 Bits Entropie. Gut für Eindeutigkeit, nicht für sicherheitsrelevante Token. Für API-Schlüssel oder Sitzungs-Tokens die Brute-Force widerstehen müssen, 256-Bit-Zufallswerte verwenden.

3.

Als binary(16) speichern, nicht varchar(36)

Eine UUID als Text hat 36 Zeichen (mit Bindestrichen). Als Binärwert sind es 16 Bytes, weniger als die Hälfte des Speicherplatzes. PostgreSQL hat einen eigenen UUID-Typ (16 Byte). MySQLs BINARY(16) mit UUID_TO_BIN() funktioniert gut. Wichtig bei Millionen von Zeilen mit UUID-Fremdschlüsseln.

4.

Bindestriche beibehalten

Das Standardformat ist 8-4-4-4-12 mit Bindestrichen. Manche Systeme entfernen sie (32 Hex-Zeichen). Beide sind gültig, aber Bindestriche machen UUIDs lesbarer und die Versionsziffer (Position 13) leichter erkennbar. Bindestriche nur entfernen wenn ein System das ausdrücklich verlangt.

Beispiele

UUID v4: reiner Zufall

Beachte die "4" an Position 13 (Version) und 8/9/a/b an Position 17 (Variante).

Input

Version: v4

Output

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7: zeitlich sortierbar

Beachte die "7" an Position 13. Die ersten 12 Hex-Zeichen codieren den Unix-Zeitstempel in Millisekunden.

Input

Version: v7

Output

018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6f

Funktionen

  • UUID v4: 122 Bits kryptographischer Zufall via crypto.randomUUID()
  • UUID v7: Millisekunden-Zeitstempel + Zufallsbits (RFC 9562)
  • Bis zu 100 UUIDs mit einem Klick generieren
  • Standard 8-4-4-4-12 Format, Kleinbuchstaben-Hex
  • Ein-Klick-Kopie für einzelne oder alle UUIDs
  • Läuft 100% im Browser, null Netzwerkanfragen

Häufige Fragen

Werden zwei UUIDs jemals kollidieren?

Für v4: Die Wahrscheinlichkeit beträgt 1 zu 2^122 (etwa 5,3 x 10^36). Du müsstest 85 Jahre lang 1 Milliarde UUIDs pro Sekunde erzeugen, um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen. In realen Systemen passiert das nicht. Für v7: noch geringeres Risiko, da der Zeitstempel sicherstellt, dass UUIDs aus unterschiedlichen Millisekunden nie kollidieren.

UUID v4 oder v7 für meine Datenbank?

v7, fast immer. Zufällige v4-UUIDs führen zu B-Baum-Index-Fragmentierung, Einfügungen landen an zufälligen Positionen, verursachen Seitenteilungen und verschlechtern die Schreibleistung. v7-UUIDs sind zeitlich geordnet, Einfügungen werden immer am Ende des Indexes angehängt. PostgreSQL-Benchmarks zeigen 2-3x besseren Insert-Durchsatz mit v7. Einziger Grund für v4: wenn du die Erstellungsreihenfolge explizit verbergen musst.

Kann man den Zeitstempel aus einer UUID v7 extrahieren?

Ja. Die ersten 48 Bits einer v7-UUID sind der Unix-Zeitstempel in Millisekunden. Nicht verschlüsselt oder versteckt. Wenn die Erstellungszeit sensible Information ist, nimm v4. Für die meisten Anwendungen (Datenbank-IDs, Ereignisprotokolle) ist die Angabe der Erstellungszeit in Ordnung und sogar nützlich.

UUID vs ULID vs nanoid?

UUID v7 und ULID lösen das gleiche Problem (zeitlich sortierbare eindeutige IDs), aber UUID v7 ist jetzt ein offizieller RFC-Standard (9562). nanoid ist kürzer (21 Zeichen vs 36), aber kein Standard. Gut für URL-Slugs, nicht für Datenbank-PKs. Für Interoperabilität und Standardkonformität UUID v7. Für kurze IDs in URLs nanoid.

Wie UUIDs effizient in einer Datenbank speichern?

Den datenbankeigenen UUID-Typ verwenden, falls vorhanden (PostgreSQL hat einen, 16 Byte). In MySQL BINARY(16) mit UUID_TO_BIN(uuid, 1) verwenden. Das Swap-Flag ordnet Bytes für bessere Indexleistung mit v1/v7 neu an. Nie als VARCHAR(36) in Tabellen mit hohem Volumen speichern, das verschwendet Speicherplatz und verlangsamt Vergleiche.

Tipps und verwandte Workflows