UUID-Generator (v4 zufällig, v7 zeitgeordnet)

Wann v4 vs. v7 verwenden

UUID v4 ist rein zufällig — 122 zufällige Bits mit zwei Versions-/Variantenbits, was etwa 5,3 × 10³⁶ mögliche Werte ergibt. Zwei kollidieren praktisch garantiert nie. v4 überall verwenden, wo keine Reihenfolge benötigt wird, wie API-Anfrage-IDs oder anonyme Nutzerkennungen.

UUID v7 (RFC 9562, veröffentlicht 2024) beginnt mit einem 48-Bit-Unix-Millisekunden-Timestamp, gefolgt von 74 zufälligen Bits. Sie sortieren lexikografisch in Erstellungsreihenfolge, was für die Datenbankleistung enorm ist — Primärschlüssel, die nach Zeit sortieren, bedeuten, dass Einfügungen immer ans Ende des B-Baums gehen, keine zufälligen Seitenteilungen. v7 für neue Datenbank-Primärschlüssel verwenden.

Wie dieser Generator funktioniert

Sowohl v4 als auch v7 verwenden crypto.getRandomValues — die sichere Zufallsquelle des Browsers, dieselbe Grundlage wie HTTPS und Passwort-Manager. v4 füllt 122 Bits zufällig. v7 teilt 48 Bits Timestamp + 74 Bits Zufall plus Versions-/Variantenmarkierungen gemäß RFC.

Die Generierung erfolgt im Browser. Die UUIDs werden weder gespeichert noch übertragen. Wenn 100 v4-UUIDs generiert werden, ist die Kollisionswahrscheinlichkeit astronomisch gering — weit unter der Wahrscheinlichkeit, dass kosmische Strahlen Bits in der CPU umkippen.

Häufige UUID-Fallstricke

v4-UUIDs als Datenbank-Primärschlüssel beeinträchtigen die Leistung im Vergleich zu auto-inkrementierenden Integern, weil zufällige Werte bei Einfügungen B-Baum-Seitenteilungen verursachen. v7 behebt das — v7 verwenden, wenn UUID-Vorteile ohne Index-Schmerzen gewünscht sind.

UUIDs nicht für Nutzer sichtbar machen, wenn Unratbarkeit wichtig ist. v4-UUIDs haben 122 Bits Entropie und sind nicht zu erraten. v7-UUIDs verraten die Erstellungszeit, was für die meisten Anwendungsfälle in Ordnung, aber schlecht ist, wenn die Erstellungszeit sensibel ist.

UUIDs sind 36 Zeichen inkl. Bindestrichen (32 Hex + 4 Bindestriche). Sie benötigen 16 Bytes binär oder 36 Bytes Text. Für Spalten mit sehr hoher Kardinalität in Erwägung ziehen, sie als binären BLOB / nativen UUID-Typ statt VARCHAR(36) zu speichern.