Was ist UUID v4?
UUID Version 4 ist ein kryptografisch zufälliger 128-Bit-Bezeichner nach RFC 4122. Von den 128 Bit werden 122 zufällig gezogen; die restlichen sechs sind festgelegt und kodieren Version (0100) und Variante (10).
v4 ist die am weitesten verbreitete Variante und die Standardwahl für Benutzer-IDs, Session-Token, API-Schlüssel und Dateinamen - überall dort, wo ein Bezeichner nichts über seine Entstehung verraten soll.
Die Mathematik hinter der Eindeutigkeit
122 Bit Entropie ergeben etwa 5,3 × 10³⁶ mögliche Werte. Nach dem Geburtstagsparadox liegt die Wahrscheinlichkeit einer Kollision erst bei rund 2,7 × 10¹⁸ erzeugten UUIDs bei 50 %.
Praktisch heißt das: Kollisionen sind kein Risiko, das Sie einplanen müssen. Wenn in der Praxis doppelte v4-UUIDs auftreten, liegt die Ursache fast immer an einer schwachen Zufallsquelle - etwa Math.random() - und nicht an der Wahrscheinlichkeit.
Erzeugung über die Web Crypto API
Dieser Generator zieht 16 Byte über crypto.getRandomValues() und setzt anschließend die Versions- und Variantenbits. Das ist der vom Browser bereitgestellte CSPRNG - dieselbe Quelle, aus der auch Schlüsselmaterial stammt.
Math.random() ist dafür ausdrücklich nicht geeignet: der Generator ist nicht kryptografisch sicher, sein Zustand lässt sich aus wenigen Ausgaben rekonstruieren, und die effektive Entropie liegt weit unter 122 Bit.
Typische Einsatzgebiete
v4 passt überall, wo ein Bezeichner keine Information tragen soll: öffentliche Objekt-IDs in REST-APIs, Idempotenzschlüssel für Zahlungsvorgänge, Korrelations-IDs im Tracing, Namen für hochgeladene Dateien, Einmal-Token in Einladungslinks.
Der Vorteil ist gleichzeitig die Einschränkung: aus einer v4 lässt sich nicht ableiten, wann sie entstanden ist. Wenn Sie diese Information brauchen, führen Sie eine eigene Zeitstempelspalte - oder verwenden v7.
UUID v4 und Datenbankleistung
Weil v4-Werte gleichmäßig über den gesamten Wertebereich streuen, landet jeder INSERT an einer zufälligen Stelle des B-Baum-Index. Das führt zu Seitenteilungen, geringerer Füllrate und mehr zufälligem I/O - bei InnoDB besonders spürbar, weil der Primärschlüssel die physische Anordnung bestimmt.
Bei einigen Millionen Zeilen ist das irrelevant. Ab etwa 100 Millionen Zeilen bringt der Wechsel auf v7 typischerweise das Zwei- bis Fünffache an INSERT-Durchsatz.
Richtig speichern
Verwenden Sie die nativen Typen: UUID in PostgreSQL, BINARY(16) in MySQL, UNIQUEIDENTIFIER in SQL Server. VARCHAR(36) verbraucht mehr als das Doppelte an Speicher und verlangsamt jeden Vergleich. Speichern Sie die Textform außerdem konsequent in Kleinbuchstaben, damit Vergleiche nicht an der Schreibweise scheitern.