UUID v4 vs. v7 in 2026: Bit-Layout, Sortierung, Indexkosten

Jede UUID ist 16 Byte groß, und die Felder sind durch ihre Position definiert, nicht durch die Bindestriche im Text. Byte 6 enthält die Version in seinem oberen Nibble. Byte 8 enthält die Variante in seinen obersten zwei Bits. Alles andere hängt von der Version ab. In der kanonischen Zeichenkette ist das 13. Hexadezimalzeichen die Version und das 17. die Variante.

Bei v4 sind die 122 Bits, die nicht Version oder Variante sind, zufällig. Bei v7 sind die ersten 48 Bits der Unix-Zeitstempel in Millisekunden, Big-Endian, weshalb v7-Werte als Rohbytes in Erstellungsreihenfolge sortieren. Die verbleibenden 74 Bits sind standardmäßig zufällig, obwohl RFC 9562 erlaubt, dass einige davon einen Zähler für Monotonie innerhalb einer Millisekunde tragen.

Eine v4-UUID ist eine Zufallszahl mit sechs festen Bits. Das obere Nibble von Byte 6 ist 0100, sodass das 13. Zeichen der kanonischen Zeichenkette immer 4 ist. Die obersten zwei Bits von Byte 8 sind 10, sodass das 17. Zeichen immer 8, 9, a oder b ist. Das sind die einzigen vorhersagbaren Zeichen; die anderen 30 Hexadezimalziffern sind zufällig.

Die Zufälligkeit ist die Sicherheitseigenschaft. Ein v4-Wert enthält keinen Zeitstempel, keine Sequenz und keine Maschinenkennung, verrät also nichts darüber, wann oder wo er erzeugt wurde. Das macht ihn zu einer vernünftigen Wahl für einen öffentlichen Bezeichner, der nicht aufzählbar sein darf, sofern er aus einer kryptografisch sicheren Zufallsquelle stammt. Ein 122-Bit-Raum macht Kollisionen vernachlässigbar: Eine Milliarde Werte ergibt eine Kollisionswahrscheinlichkeit von etwa 2^-63.

Eine v7-UUID ist zeitgeordnet. Die Bytes 0 bis 5 enthalten die Anzahl der Millisekunden seit der Unix-Epoche, Big-Endian. Das obere Nibble von Byte 6 ist 0111. Das untere Nibble von Byte 6 und das gesamte Byte 7 bilden rand_a, die obersten zwei Bits von Byte 8 sind die Variante, und die verbleibenden 62 Bits sind rand_b. Das sind 74 zufällige Bits plus ein Zeitstempel, der durch bloßes Ansehen lesbar ist.

Der Zeitstempel ist 48 Bit lang, was für Millisekunden bis zum Jahr 10889 ausreicht, sodass ein Überlauf kein praktisches Problem darstellt. Zwei v7-Werte, die in derselben Millisekunde erzeugt wurden, unterscheiden sich nur in ihren zufälligen Bits oder Zählerbits, und ein später erzeugter Wert vergleicht sich als Byte-String immer größer als ein früher erzeugter, solange die Uhr nicht rückwärts läuft. Diese Ordnung ist der ganze Sinn der Sache.

Die lexikografische Sortierung der kanonischen Textform entspricht der Byte-Reihenfolge, weil die Bindestriche an festen Positionen stehen und Hexadezimalziffern in derselben Reihenfolge sortieren wie ihre Werte, wenn sie kleingeschrieben sind. Sortiert man nach der Textform oder nach den 16 Bytes, erhält man die Erstellungsreihenfolge. Das gilt maschinenübergreifend ohne Koordination, weshalb v7 für Ereignisprotokolle und für Bezeichner, die Teil eines Sortierschlüssels werden, attraktiv ist.

Die Lücke liegt innerhalb einer einzelnen Millisekunde. Standardmäßig werden zwei in derselben Millisekunde erzeugte Werte nach ihren zufälligen Bits geordnet, was nicht der Erstellungsreihenfolge entspricht. RFC 9562 beschreibt die Verwendung des rand_a-Felds oder der linkesten zufälligen Bits als Zähler, der bei jedem Zeitstempel-Tick zufällig initialisiert wird. Mit dieser Methode sind Werte für praktische Zwecke innerhalb einer Millisekunde monoton, auf Kosten von etwas weniger Zufälligkeit und einem gemeinsamen Zähler, der von gleichzeitigen Erzeugern sorgfältig behandelt werden muss.

Ein zufälliger v4-Primärschlüssel wird an einer zufälligen Position im Index eingefügt. In einem B-Tree bedeutet das, bei fast jedem Einfügen eine andere Blattseite anzufassen, Seiten aus dem Buffer-Pool zu verdrängen und Seiten in der Mitte zu teilen, wodurch sie halb voll zurückbleiben. Der Index wächst, die Write Amplification steigt, und die Cache-Trefferquote sinkt, je größer die Tabelle wird.

Ein v7-Schlüssel wird nahe der rechten Kante eingefügt, sodass das Arbeits-Set klein bleibt und Seitenteilungen am Ende stattfinden, wo sie günstig sind. Der Kompromiss ist Konkurrenz: Jeder Schreiber will dieselbe rechteste Seite. Bei einer einzelnen Datenbank ist das mit einigen hundert Schreibvorgängen pro Sekunde meist in Ordnung; bei sehr hoher Nebenläufigkeit wird es zum Hotspot, und die üblichen Gegenmaßnahmen sind Batching, Verschachtelung auf Verbindungsebene oder ein wenig Jitter in den hohen Bits.

Ein v7-Wert verrät jedem, der ihn besitzt, ungefähr, wann er erzeugt wurde – auf die Millisekunde genau – und damit, wie viele andere Datensätze rund um diesen Zeitpunkt erzeugt wurden. Das ist für interne Schlüssel und Ereignis-IDs in Ordnung. Es ist nicht in Ordnung für einen öffentlichen Bezeichner, der weder Anmeldevolumen noch Bestellrate noch das Alter eines Kontos preisgeben soll.

Wenn Sie sowohl Ordnung als auch Undurchsichtigkeit benötigen, besteht die Wahl darin, v7 intern zu halten und eine separate zufällige öffentliche ID herauszugeben oder v4 für alles zu verwenden, was Ihr System verlässt. Betrachten Sie eine UUID in keiner der beiden Versionen als Capability-Token; beide sind Bezeichner, keine Autorisierung. Eine v4-ID ist in der Praxis nicht erratbar, muss aber trotzdem bei jeder Anfrage gegen die Zugriffskontrolle geprüft werden.

Sechzehn Bytes ist die Speicherantwort für beide Versionen. Die kanonische Textform hat 36 Zeichen, davon 32 Hexadezimalziffern und 4 Bindestriche. Das Speichern der Textform verdoppelt die Größe und verlangsamt Vergleiche, daher einen nativen UUID-Typ verwenden, wo es einen gibt, BINARY(16), wo es keinen gibt, und nur an der Grenze formatieren.

SQL Server hat eine Eigenheit, die es zu testen lohnt: Sein uniqueidentifier-Typ sortiert in einer Byte-Reihenfolge, die nicht mit der kanonischen Zeichenkette übereinstimmt, und die interne Byte-Reihenfolge weicht von RFC 4122 ab. Code, der sich auf die v7-Ordnung verlässt, muss das Sortierverhalten auf dieser Plattform überprüfen, statt es anzunehmen. Wo Sie eine kompakte Textform benötigen, ergibt base64url ohne Padding 22 Zeichen, aber es ist keine standardkonforme UUID-Darstellung und wird Werkzeuge verwirren, die die kanonische Form erwarten.

Wählen Sie v7, wenn der Bezeichner ein Datenbankschlüssel ist, wenn Sie nach Erstellungszeit sortieren möchten, ohne eine zweite Spalte zu benötigen, oder wenn Sie eine stark schreiblastige Tabelle aufbauen. Wählen Sie v4, wenn der Wert öffentlich preisgegeben wird, wenn die Erstellungszeit sensibel ist oder wenn das System bereits eine Zeitstempelspalte speichert und von der Ordnung nichts gewinnt. Beide sind für unterschiedliche Randbedingungen die richtige Wahl, und sie in einer Tabelle zu mischen ist meist ein Fehler.

Tests müssen die Struktur prüfen, nicht die Werte. Prüfen Sie das Versions-Nibble, das Varianten-Nibble und die Bytelänge nach dem Parsen. Bei v7 prüfen Sie, dass der eingebettete Zeitstempel im Testfenster liegt und dass zwei in Reihenfolge erzeugte Werte korrekt vergleichen. Speichern Sie niemals eine literale UUID als Snapshot in einem Test, und prüfen Sie niemals, dass eine v7 strikt größer als die vorherige ist, es sei denn, der Generator verwendet einen Zähler; ohne einen ist die Reihenfolge innerhalb derselben Millisekunde zufällig.