UUID Generator: V1, V4, V7 uitgelegd (en welke daadwerkelijk te gebruiken)

De eerste keer dat UUID's er echt toe deden voor mij, was ik een aan WordPress aangrenzende SaaS aan het verplaatsen van een enkele MySQL-box naar een setup met een gelezen replica en een plan om later te sharden. Auto-increment ID's waren al jaren prima - totdat twee services begonnen te worden ingevoegd in wat dezelfde logische tabel zou worden, en plotseling id = 42 betekende twee verschillende rijen. Dat is het moment waarop auto-increment stilletjes stopt met werken, en UUID's zijn het gebruikelijke antwoord.

Een UUID is een 128-bits waarde die u op elk apparaat kunt genereren, op elk moment, zonder coördinatie, en toch vertrouwen om uniek te zijn. Dat "geen coördinatie" deel is het hele punt: een mobiele app offline op een vliegtuig, drie microservices en een achtergrondwerker kunnen allemaal tegelijkertijd ID's gebruiken en nooit botsen. De wiskunde die dat vertrouwen ondersteunt, is echt absurd, en ik zal je laten zien hoe absurd in een seconde.

de UUID-generator op Toolz.dev maakt enkele of bulk UUID's in meerdere versies direct, direct in uw browser - handig wanneer u ' een tabel zaait of een wegwerp-ID nodig heeft voor een test Deze handleiding behandelt wat de versies eigenlijk betekenen, welke u in 2026 moet kiezen, hoe u ze kunt opslaan zonder uw database-index te vernietigen, en de fouten die ik heb gemaakt zodat u ze kunt overslaan.

tl;dr: Voor nieuwe primaire sleutels van de database in 2026, genereer uuid v7- it's tijdgeordend zodat het goed indexeert, en dat doet het ook 't lekt hardware zoals v1. Gebruik v4 Wanneer je pure onvoorspelbaarheid wilt. bewaar ze als een inboorling uuid typ of BINARY(16), nooit VARCHAR(36). maak ze in bulk met de UUID-generator, en koppel het met de tijdstempel converter Om de tijd gebakken in een V7 te lezen. Alle client-side, allemaal gratis.

Wat is precies een UUID?

Een UUID (Universally Unique Identifier) is een 128-bits nummer dat wordt gebruikt om iets te identificeren zonder dat een centrale autoriteit ID's uitdeelt Microsoft noemt hetzelfde een GUID (Globally Unique Identifier); zij ' zijn op alle mogelijke manieren identiek De canonieke tekstvorm is 36 tekens - 32 hex-cijfers opgesplitst in vijf afgebroken groepen van 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

Twee van die hex-posities zijn't willekeurige gegevens - zij're metadata Het 13e hex-cijfer codeert de vertaling (welke generatiestrategie heeft het gemaakt), en het eerste cijfer van de vierde groep codeert de verschillend (welke lay-outstandaard volgt het - 8, 9, a, of b voor de standaard UUID's). Dus in het bovenstaande voorbeeld is de 4 In de derde groep vertelt je dat het een V4 is.

Hoe uniek is "Uniek" echt?

Nadat de versie en variant bits zijn gereserveerd, heeft een V4 UUID 122 willekeurige bits. Dat is 2^122 mogelijke waarden, of ongeveer 5,3 onbedecillion:

5,316,911,983,139,663,491,615,228,241,121,400,000

Om dat concreet te maken: als je elke seconde een miljard UUID's genereert, heb je ongeveer 86 jaar nodig voordat je zelfs maar 50% kans op een enkelspel botsingen overal. In praktische technische termen gebeuren V4-botsingen niet en kunt u ontwerpen alsof ze dat nooit zullen doen.

Wat is het verschil tussen UUID V1, V4 en V7?

De specificatie - oorspronkelijk RFC 4122, nu bijgewerkt door RFC 9562 (2024)- definieert verschillende versies Drie zaken voor het dagelijkse werk.

UUID v1 - tijdstempel + MAC-adres

v1 sluit een tijdstempel van 100 nanoseconden aan elkaar (geteld vanaf 15 oktober 1582, de datum waarop de Gregoriaanse kalender begon - een van mijn favoriete stukjes spec-trivia) met de netwerkkaart & #39; s MAC-adres. It' s natuurlijk in de tijd besteld en je kunt er de aanmaaktijd uit halen.

Het probleem zit precies in de definitie: het sluit het MAC-adres van de machine die het heeft gemaakt in. Dat lekt hardware-identiteit en, in combinatie met de tijdstempel, maakt IDS enigszins voorspelbaar. Voorbeeld: 6ba7b810-9dad-11d1-80b4-00c04fd430c8. Ik gebruik nu alleen v1 voor legacy-compatibiliteit.

UUID v4 - willekeurig

V4 is 122 bits willekeur en niets anders. Het is de versie die de meeste mensen bedoelen als ze "uuid" zeggen, en het is doodeenvoudig: geen tijdstempel, geen hardware, geen bestelling. Voorbeeld: f47ac10b-58cc-4372-a567-0e02b2c3d479.

Het voordeel is dat het niets lekt en onvoorspelbaar is, en dat is precies wat je wilt voor alles wat niet te raden is. Het nadeel is dat het is op goed geluk, dus opeenvolgende invoegingen verspreiden zich over je hele index - wat, zoals ik ontdekte, op grote schaal echte prestatiekosten met zich meebrengt.

UUID v7 - tijdgeordend + willekeurig

V7 is het moderne compromis, gestandaardiseerd in RFC 9562. De eerste 48 bits zijn een Unix-tijdstempel in milliseconden, de rest is willekeurig. Voorbeeld: 018e4880-d4d0-7b9c-8c37-2a5c0f1e3d8a.

Die lay-out betekent dat v7 ID's chronologisch sorteren - nieuwe rijen landen op de & quot;end" van een B-boomindex in plaats van verstrooiing - terwijl ze nog steeds globaal uniek en coördinatievrij zijn Het lekt bij benadering de aanmaaktijd (meestal prima) maar geen hardware Voor nieuwe projecten is dit mijn standaard primaire sleutel, en het & #39; is de richting die de IETF nu ook wijst.

Hier is de afweging in één oogopslag:

De versies met minder gebruikte bestaan bestaan ook: v3 en v5 zijn deterministische hashes van een naamruimte plus een naam (v5 gebruikt SHA-1 en heeft de voorkeur boven v3's MD5), v6 is een herschikte v1 en v8 is gereserveerd voor aangepaste implementaties.

Moet u UUID's of automatische verhogings-ID's gebruiken?

Dit is het debat dat ik had in meer ontwerprecensies dan alle andere, dus hier is het kader dat ik eigenlijk gebruik in plaats van een religieus antwoord.

Blijf bij automatische increment wanneer u hebt een enkele database, de prestaties en opslag zijn krap, en mensen moeten de ID's lezen Een geheel getal is 4-8 bytes versus een UUID's 16, vergelijkingen van gehele getallen zijn sneller, en "order #12345" is een stuk gemakkelijker om de telefoon af te lezen dan een UUID van 36 tekens. Op een enkele doos zonder sharding is automatische verhoging echt de eenvoudigere, snellere keuze - don' bereik niet uit de mode voor UUID's.

overschakelen naar UUID's wanneer elk van deze is waar: u ' worden gedistribueerd (meerdere services of servers die onafhankelijk ID's slaan), u ' maak je zorgen over opsomming (auto-increment-ID's zijn raadbaar en onthullen stilletjes uw recordtellingen - /users/1234 Vertelt een aanvaller dat u minder dan 1.235 gebruikers heeft, u moet gegevens uit meerdere databases samenvoegen zonder botsingen, of u wilt dat clients ID's genereren voordat ze worden gesynchroniseerd. Dat sommen punt is een echte veiligheidsoverweging die mensen onderschatten.

En de V7 middenweg: UUID V7 geeft u de gedistribueerde generatie van een UUID en De indexvriendelijke volgorde van automatische incratie, zonder lekkende recordtellingen. Voor de meeste nieuwe projecten in 2026 die niet-sequentiële ID's nodig hebben, is V7 het antwoord dat het debat beëindigt.

Hoe bewaar je UUID's zonder je index te slopen?

Dit is het gedeelte dat voortkomt uit mijn eigen dure fout, dus let hier op als nergens anders.

Bij die migratie die ik noemde, heb ik de nieuwe UUID's opgeslagen als VARCHAR(36) omdat het voor de hand liggend en leesbaar was om te doen. Het werkte - en toen groeide de tafel, en het inbrengen en samenvoegen werd meetbaar langzamer. Twee problemen werden nog groter: ik gaf 36 bytes per ID uit in plaats van 16 en Ik gebruikte willekeurige V4 UUID's, dus elk insert belandde op een willekeurige plek in de primaire sleutelindex, fragmenteerde het en versloeg de bufferpool. De oplossing was ze op te slaan als binair en, bij het volgende project, overschakelen naar V7, dus inserts bleven opeenvolgend.

Postgresql heeft een inheems uuid type - gebruik het Het slaat 16 bytes op en vergelijkt snel:

CREATE EXTENSION IF NOT EXISTS "pgcrypto";

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

mysql Heeft geen native UUID-type, dus sla op BINARY(16) en converteren met UUID_TO_BIN() / BIN_TO_UUID(). Het tweede argument is van belang:

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- The `true` swaps the timestamp bytes for better index locality on v1
INSERT INTO users (id, name, email)
VALUES (UUID_TO_BIN(UUID(), true), 'Alice', '[email protected]');

SELECT BIN_TO_UUID(id, true) AS id, name, email FROM users;

De regel om te onthouden: Native uuid typ waar je er een hebt, BINARY(16) waar je niet, en VARCHAR(36) In principe nooit voor een sleutel die je zult indexeren en meedoen.

Hoe genereer je UUID's in code?

Voor een snelle eenmalige UUID-generator is sneller dan het openen van een REPL. In code heeft elke grote taal dit ingebouwd of een stap verwijderd.

JavaScript / Typescript- de browser en Node verzenden nu allebei een v4-generator:

const id = crypto.randomUUID();   // v4, no dependency needed
// For v7, use the 'uuid' package:
import { v7 as uuidv7 } from 'uuid';
const ordered = uuidv7();

Python:

import uuid
uuid.uuid4()                                  # random
uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com') # deterministic (SHA-1)

java: UUID.randomUUID() Geeft je v4 uit de doos; V7 heeft een bibliotheek nodig java-uuid-generator of een kleine RFC 9562-implementatie.

gaan: github.com/google/uuid geeft je beide - uuid.New() Voor V4 en uuid.NewV7() voor V7.

Merk op dat native runtime-helpers je bijna altijd V4 geven. Als je specifiek V7 wilt voor de bestelling, heb je meestal een bibliotheek nodig, omdat het de nieuwere standaard is en niet elke stdlib heeft ingehaald.

Waar verschijnen UUID's eigenlijk in echte systemen?

Het is gemakkelijk om in abstracto over UUID's te praten, dus hier zijn de concrete plaatsen waar ik op heb vertrouwd, omdat de versie die je kiest echt afhangt van het werk.

Primaire databasesleutels in een gedistribueerde setup. Dit is het klassieke geval en degene die dit artikel voor mij heeft gestart Het moment dat meer dan één schrijver in dezelfde logische tabel kan invoegen - replica's, shards of twee services die een schema delen - pauzes voor automatische verhoging Een v7 primaire sleutel lost het coördinatieprobleem op en indexeert nog steeds netjes omdat het ' s tijdgeordend is.

Door clients gegenereerde ID's voor offline-eerste apps. Een mobiele app of een browser SPA moet vaak een record maken voordat het met de server kan praten - denk aan een notitie geschreven in een vliegtuig, of een optimistische gebruikersinterface die de nieuwe rij onmiddellijk laat zien. Als de client vooraf een UUID laat knippen, heeft de plaat een stabiele identiteit vanaf de eerste toetsaanslag en wordt later gesynchroniseerd zonder retour van de server naar " haal een ID." I' Ik heb dit gebruikt om formulieren direct te laten aanvoelen, zelfs bij schilferige verbindingen.

Niet-opmerkzame resource-ID's in URL's en API's. vorming /orders/1042 In een URL vertelt u stilletjes aan iedereen dat u maximaal 1.042 bestellingen had en ze laten lopen /orders/1041, /orders/1040, enzovoort. Door in een UUID te wisselen, worden zowel het business-metrische lek als de eenvoudige opsomming verwijderd. Voor alles wat een gebruiker in een URL kan zien, is dit de moeite waard - hoewel onthoud dat een UUID geen toegangscontrolemechanisme is; je hebt er nog steeds echte autorisatiecontroles achter nodig.

Correlatie-ID's voor tracering. Wanneer een enkel verzoek over vijf microservices uitwaaiert, één UUID als correlatie-ID bevestigt en deze bij elke hop registreert, verandert & quot; ergens in deze puinhoop is er iets mislukt" in een enkele greppable string over al uw logboeken. Dit is een plek waar zelfs een gewone v4 perfect is - u hoeft niet te bestellen ' je hebt bestellen nodig, alleen maar uniekheid.

Idempotentiesleutels. Betalings- en Webhook-API's vragen de klant vaak om een UUID als idempotency-sleutel te sturen, zodat een opnieuw berecht verzoek niet twee keer een kaart in rekening brengt. De client genereert het één keer, hergebruikt het bij nieuwe pogingen en de server ontdooit erop. Het is een klein patroon dat een zeer dure klasse van bugs voorkomt.

Veelgestelde vragen

Waar wordt een UUID voor gebruikt?

Een UUID identificeert op unieke wijze iets - een databaserij, een API-bron, een sessie, een geüpload bestand, een spoor over microservices - zonder dat er een centrale service nodig is om ID's uit te delen. It' is de go-to wanneer meerdere systemen of clients onafhankelijk identificatiegegevens moeten maken en er toch zeker van moeten zijn dat ze zullen winnen't botsen. U kunt er direct een genereren met de UUID-generator op Toolz.dev.

Kunnen twee UUID's ooit identiek zijn?

In theorie ja; in de praktijk nee. Een V4 UUID heeft 122 willekeurige bits, wat ongeveer 5,3 onbedecillioneerde mogelijkheden biedt. U moet in de orde van 2,7 quintillion UUID's genereren voordat u een kans van 50% op zelfs één botsing bereikt. Voor elk echt technisch doel kunt u UUID's als gegarandeerd uniek behandelen.

Welke UUID-versie moet ik in 2026 gebruiken?

Voor nieuwe primaire databasesleutels, UUID v7 - it' s tijdgeordend voor efficiënte indexering terwijl het wereldwijd uniek blijft, en it' is de huidige IETF-aanbeveling onder RFC 9562. gebruik v4 wanneer onvoorspelbaarheid ertoe doet, zoals identificatiegegevens die niet raadbaar mogen zijn Vermijd v1 voor nieuw werk omdat het de genererende machine insluit's MAC-adres.

zijn UUID's opeenvolgend?

v1 en v7 zijn in de tijd geordend, dus ID's die later worden gegenereerd, sorteren op eerdere; v4 is volledig willekeurig zonder volgorde. Sequentiële ordening is wat v7 vriendelijk maakt voor B-boomindexen - nieuwe rijen worden toegevoegd in plaats van verspreid. Als u ' willekeurige v4 als primaire sleutel op een grote tafel gebruikt, kan dat gebrek aan volgorde de invoeg- en indexprestaties schaden.

Hoe moet ik UUID's opslaan in een database?

Gebruik de inheems uuid Typ als uw database er één heeft (postgresql wel). anders opslaan BINARY(16)en in MySQL 8.0+ Converteren met UUID_TO_BIN() en BIN_TO_UUID(). vermijden VARCHAR(36) of CHAR(36) voor sleutels verspilt stringopslag 20 bytes per rij en vertraagt elke vergelijking, wat snel op grote tabellen neerkomt.

Wat is het verschil tussen een UUID en een GUID?

Ze zijn hetzelfde. UUID is de term van RFC 4122 die in de meeste talen en platforms wordt gebruikt; GUID is de naam van Microsoft voor IT, gebruikelijk in Windows en .NET. Het formaat en de garanties zijn identiek, zodat u een GUID en een UUID door elkaar kunt behandelen.

Kan ik de aanmaaktijd uit een UUID halen?

Van v1, v6 en v7, ja - ze coderen een tijdstempel. v7 slaat een Unix-tijdstempel van milliseconden op in de eerste 48 bits, die je kunt decoderen en lezen met de tijdstempel converter. V4 en V5 bevatten geen tijdinformatie, dus er is niets om uit te halen.

Is uuid v4 veilig genoeg voor sessietokens?

niet op zich. V4's 122 willekeurige bits zijn onvoorspelbaar, maar sessie- en authenticatietokens willen over het algemeen ten minste 256 bits van een cryptografisch beveiligde generator. Gebruik een speciaal gebouwde beveiligde willekeurige token voor auth en reserveer UUID's voor het identificeren van bronnen in plaats van ze te beschermen.

Hoe genereer ik een UUID?

Gebruik de ingebouwde generator van uw taal: crypto.randomUUID() In moderne browsers en node.js, uuid.uuid4() in Python, of Guid.NewGuid() In .NET produceren elk een V4 UUID in een enkele oproep. Voor een snelle eenmalige of een batch, genereer ze direct met de UUID-generator op Toolz.dev - geen code nodig.

Hoeveel karakters is een UUID?

Een UUID is 36 tekens in zijn canonieke tekstvorm: 32 hexadecimale cijfers plus de vier koppeltekens die het in 8-4-4-4-12 groepen splitsen. Die tekst codeert 128 bits, daarom wordt het opgeslagen als 16 onbewerkte bytes met BINARY(16) is veel compacter dan de 36-karakter string.

inpakken

UUID's zijn een van die fundamenten die je don' niet over nadenken totdat een systeem langs één enkele database groeit - en dan zijn ze ' alles. De korte versie uit 2026: standaard naar V7 Gebruik voor nieuwe primaire sleutels: v4 Wanneer u ongewenste ID's nodig heeft, sla ze op als natuurlijk uuid of BINARY(16), en sla v1 over voor iets nieuws. leer van mijn VARCHAR(36) middag, dus je herhaalt het niet.

genereer ze direct met de gratis UUID-generator op Toolz.dev - enkel of bulk, elke versie, alle client-kant met niets geüpload Wanneer u de tijd in een v7 moet lezen, reik dan naar de tijdstempel converteren blader door de rest van de Coderingstools- 600+ gratis hulpprogramma's - meer dan Toolz.dev.