UUID (Universally Unique Identifier)

Generieren: Fast jede Sprache hat eine Library. uuid.v4() (Random). Als Primary Key in der Datenbank nutzen, statt INT.

Vorteil Security: Wenn deine URL user/5 heißt, weiß ich, dass es user/6 gibt (Enumeration Attack). Bei user/a8f3... kann ich nicht raten.

1. Versionen (v1, v4, v7)

• v1 (Time + MAC): Enthält deine MAC-Adresse und Uhrzeit. Datenschutz-Problem! (Man weiß, wer es wann erstellt hat).
• v4 (Random): Der Standard. 100% Zufall.
• v7 (Time + Random): Neu! Sortierbar nach Zeit. Besser für Datenbank-Indexe (Performance), da neuere Einträge immer "unten" landen.

2. Performance (Das Index-Problem)

UUIDs sind groß (128 Bit) und chaotisch verteilt. Auto-Increment IDs (64 Bit) sind klein und geordnet. In großen Datenbanken (MySQL/Postgres) fragmentieren UUIDs den Index. Das Einfügen wird langsamer. Lösung: UUIDv7 oder ULID (Universally Unique Lexicographically Sortable Identifier).

3. Kollisionswahrscheinlichkeit

Bei v4 gibt es $2^{122}$ Kombinationen. Du müsstest 100 Jahre lang jede Sekunde eine Milliarde UUIDs generieren, um eine 50% Chance auf eine Kollision zu haben. In der Praxis: Ignoriere Kollisionen. Sie passieren nicht.

1. Das Birthday Paradox (Kollisions-Mathematik)

Warum ist v4 (Zufall) sicher? Eine UUID hat 122 zufällige Bits. Das ergibt $5,3 \times 10^{36}$ Möglichkeiten. Das Birthday Paradox besagt, dass Wahrscheinlichkeiten für Dubletten viel früher steigen als gedacht. Trotzdem: Um eine Wahrscheinlichkeit von eins zu einer Milliarde für eine einzige Kollision zu haben, müsstest du über einen Zeitraum von vielen Jahren insgesamt 103 Billionen UUIDs generieren. Für fast alle menschlichen Projekte bedeutet das: Die Chance ist de facto Null. In dezentralen Systemen (Microservices) ist dies der heilige Gral, da man IDs erzeugen kann, ohne eine zentrale Datenbank nach der nächsten freien Nummer zu fragen.

2. Sequential UUIDs (Datenbank-Killer-Feature)

Klassische UUIDs (v4) sind völlig ungeordnet. Wenn du sie als Primary Key nutzt, müssen Datenbanken bei jedem neuen Eintrag den gesamten B-Tree Index im RAM umbauen ("Page Thrashing"). UUID v7 löst dies, indem die ersten 48 Bits die aktuelle Unix-Zeit in Millisekunden enthalten. Vorteil:

• Sie sind zeitlich sortierbar.
• Neue Einträge landen im Index immer "rechts außen", was das Einfügen fast so schnell macht wie bei einer klassischen Auto-Increment-ID.
• Dennoch bleibt die globale Eindeutigkeit durch die nachfolgenden Zufalls-Bits erhalten.

3. Binäre Speicherung vs. String

Ein fataler Anfängerfehler ist das Speichern der UUID als Text (VARCHAR(36)). Die UUID 550e8400-e29b-11d4-a716-446655440000 belegt als Text 36 Bytes. Intern sind es aber nur 16 Bytes (128 Bit). Moderne Datenbanken wie PostgreSQL haben einen spezialisierten Datentyp UUID. MySQL-Nutzer sollten BINARY(16) verwenden und die Bindestriche beim Speichern weglassen. Das halbiert nicht nur den Speicherplatz auf der Platte, sondern beschleunigt auch Index-Lookups und Joins massiv, da der Computer 16-Byte-Blöcke viel schneller vergleichen kann als lange Strings.