UUID erzeugen
v4 ist reiner Zufall; v7 stellt 48 Bit Zeitstempel voran, wodurch die Kennungen zeitlich aufsteigen — und genau das ändert alles für einen Datenbankindex.
Die Ziehung nutzt crypto.randomUUID() bzw. crypto.getRandomValues(), die kryptografische API des Browsers. Nichts wird gesendet oder gespeichert.
So funktioniert die Prüfung
- 1
Version wählen
v4 für eine Kennung ohne Ordnung und ohne Bedeutung. v7, wenn die Kennungen Primärschlüssel oder Indexeinträge sind: sie sortieren sich von selbst nach Erstellungszeit.
- 2
Die Ziehung ist kryptografisch
122 Bit Zufall bei v4. Eine Kollision ist theoretisch möglich und praktisch unerreichbar: es bräuchte Milliarden Kennungen pro Sekunde über ein Jahrhundert.
- 3
Versions- und Variantenbits werden gesetzt
Eine normgerechte UUID trägt ihre Versionsnummer am 13. Hex-Zeichen und ihre Variante am 17. Ein Generator, der das vergisst, erzeugt eine Zeichenkette, die wie eine UUID aussieht, ohne eine zu sein.
Warum v7 als Primärschlüssel oft besser ist
Ein B-Tree-Index mag geordnete Einfügungen. Mit v4-UUIDs landet jede Einfügung an zufälliger Stelle im Index, fragmentiert Seiten und treibt das Schreibvolumen hoch. Mit v7 hängen sich neue Zeilen hinten an, wie eine hochzählende ID.
Der Preis: eine v7-UUID verrät den Erstellungszeitpunkt auf die Millisekunde. Meist kein Geheimnis — ist die Reihenfolge der Erstellung selbst heikel, bleibt v4 die richtige Wahl.
Häufige Fragen
Können zwei UUIDs identisch sein?
Mathematisch ja, praktisch nein. Eine v4-UUID trägt 122 Bit Zufall: eine Milliarde pro Sekunde über hundert Jahre ließe die Kollisionswahrscheinlichkeit noch immer vernachlässigbar. Die wahre Quelle von Dubletten ist ein schlecht implementierter Generator ohne kryptografische Zufallsquelle.
Was unterscheidet v1, v4 und v7?
v1 verbindet Zeitstempel und MAC-Adresse der Maschine und verrät damit Hardware. v4 ist reiner Zufall. v7, in RFC 9562 normiert, behält die zeitliche Ordnung von v1, ohne Hardware preiszugeben: heute der beste Kompromiss für einen Primärschlüssel.
UUID als Text oder binär speichern?
Binär, wo die Datenbank es zulässt: 16 Byte gegen 36 Zeichen, also weniger als die Hälfte des Platzes in jedem Index. PostgreSQL hat einen nativen uuid-Typ; MySQL nutzt BINARY(16) mit UUID_TO_BIN(). Als Text zahlen Sie diesen Platz in jeder Zeile und jedem Indexeintrag.
Dieselbe Prüfung per API
Dieses Werkzeug läuft in Ihrem Browser. Für dieselbe Prüfung aus Ihrem Code, in großer Menge oder serverseitig, antwortet die API in JSON.
Zur Dokumentation