Generatore UUID: V1, V4, V7 spiegato (e quale effettivamente utilizzare)

La prima volta che gli UUID contavano davvero per me, stavo spostando un SaaS adiacente a WordPress da un singolo box MySQL a una configurazione con una replica in lettura e un piano per sharding in seguito Gli ID di incremento automatico andavano bene da anni - finché due servizi non iniziarono a inserirsi in quella che sarebbe diventata la stessa tabella logica, e all'improvviso id = 42 significava due righe diverse. Questo è il momento in cui l'incremento automatico smette di funzionare silenziosamente e gli UUID sono la solita risposta.

Un UUID è un valore a 128 bit che puoi generare su qualsiasi macchina, in qualsiasi momento, senza coordinamento, e comunque confidare per essere unico. Quella parte di "nessuna coordinazione" è il punto centrale: un'app mobile offline su un aereo, tre microservizi e un lavoratore in background può tutti gli ID contemporaneamente e non si scontrano mai. La matematica che sostiene quella fiducia è davvero assurda e ti mostrerò quanto assurdo in un secondo.

la Generatore di UUID su Toolz.dev crea UUID singoli o di massa in più versioni istantaneamente, direttamente nel tuo browser - a portata di mano quando tu' stai seminando una tabella o hai bisogno di un ID usa e getta per un test Questa guida copre cosa significano effettivamente le versioni, quale scegliere nel 2026, come archiviarle senza distruggere l'indice del tuo database e gli errori che ho commesso in modo che tu possa saltarle.

tl; dr: Per le chiavi primarie del nuovo database nel 2026, generare uuid v7- it' è ordinato nel tempo, quindi indicizza bene e perde hardware come v1. Usa v4 Quando vuoi pura imprevedibilità. Conservali come nativi uuid tipo o BINARY(16), mai VARCHAR(36). farli alla rinfusa con il Generatore di UUID, e abbinalo al Convertitore di timestamp Per leggere il tempo incastonato in un V7. Tutto lato client, tutto gratuito.

Cos'è un UUID, esattamente?

Un UUID (Universalally Unique Identifier) è un numero a 128 bit utilizzato per identificare qualcosa senza che un'autorità centrale distribuisca ID. Microsoft chiama la stessa cosa GUID (Globally Unique Identifier); loro' sono identici in ogni modo che conta La forma di testo canonica è di 36 caratteri - 32 cifre esadecimali suddivise in cinque gruppi con trattino di 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

Due di queste posizioni esadecimali sono & #39; t dati casuali: loro & #39;re metadati. La tredicesima cifra esadecimale codifica il versione (quale strategia di generazione l'ha realizzata) e la prima cifra del quarto gruppo codifica per variazione (quale standard di layout segue - 8, 9, a, o b per gli UUID standard). Quindi nell'esempio sopra, il 4 Nel terzo gruppo ti dice che è un V4.

Quanto è unico "unico, davvero?

Dopo che la versione e la variante sono state riservate, un UUID V4 ha 122 bit casuali. Questo è 2^122 valori possibili, o circa 5,3 indecili:

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

Per renderlo concreto: se hai generato un miliardo di UUID ogni secondo, avresti bisogno di circa 86 anni prima di raggiungere anche una probabilità del 50% di unico Collisione ovunque. In termini di ingegneria pratica, le collisioni V4 non si verificano e puoi progettare come se non lo facessero mai.

Qual è la differenza tra UUID V1, V4 e V7?

La specifica - originariamente RFC 4122, ora aggiornato da RFC 9562 (2024)- definisce diverse versioni Tre contano per il lavoro quotidiano.

UUID v1 - timestamp + indirizzo MAC

v1 unisce un timestamp di 100 nanosecondi (contando dal 15 ottobre 1582, data di inizio del calendario gregoriano - una delle mie curiosità specifiche preferite) con la scheda di rete's Indirizzo MAC. It's naturalmente ordinato nel tempo e puoi estrarre da esso il tempo di creazione.

Il problema è proprio lì nella definizione: incorpora l'indirizzo MAC della macchina che l'ha creata. Ciò perde l'identità hardware e, combinato con il timestamp, rende gli ID alquanto prevedibili. Esempio: 6ba7b810-9dad-11d1-80b4-00c04fd430c8. Ora uso solo la v1 per la compatibilità legacy.

UUID v4 - casuale

V4 è 122 bit di casualità e nient'altro. È la versione che la maggior parte delle persone intendo quando dice "uuid, ed è molto semplice: nessun timestamp, nessun hardware, nessun ordine. Esempio: f47ac10b-58cc-4372-a567-0e02b2c3d479.

Il vantaggio è che non perde nulla ed è imprevedibile, che è esattamente quello che vuoi per tutto ciò che non dovrebbe essere supponente. Il rovescio della medaglia è che è casuale, quindi gli inserti consecutivi si diffondono su tutto il tuo indice, il che, come ho scoperto, ha un costo di prestazione reale su larga scala.

UUID v7 - ordinato nel tempo + casuale

V7 è il moderno compromesso, standardizzato in RFC 9562. I primi 48 bit sono un timestamp UNIX in millisecondi; il resto è casuale. Esempio: 018e4880-d4d0-7b9c-8c37-2a5c0f1e3d8a.

Quel layout significa che gli ID v7 ordinano cronologicamente - le nuove righe atterrano al & quot; end" di un indice B-tree invece di scattering - pur essendo univoci a livello globale e privi di coordinazione Perde tempo approssimativo di creazione (di solito fine) ma non hardware Per i nuovi progetti, questa è la mia chiave primaria predefinita, e it' è la direzione che punta ora anche l'IETF.

Ecco il compromesso a colpo d'occhio:

Esistono anche le versioni meno utilizzate: V3 e V5 sono hash deterministici di uno spazio dei nomi più un nome (V5 utilizza SHA-1 ed è preferito rispetto a V3's MD5), V6 è un V1 riordinato e V8 è riservato alle implementazioni personalizzate.

Dovresti usare UUID o ID di incremento automatico?

Questo è il dibattito che ho avuto in più recensioni di design di qualsiasi altra, quindi ecco la struttura che uso effettivamente piuttosto che una risposta religiosa.

attenersi all'auto-incremento quando hai un singolo database, le prestazioni e l'archiviazione sono limitate e gli esseri umani devono leggere gli ID. Un numero intero è 4U8 byte rispetto a un UID' 16, i confronti tra numeri interi sono più veloci e & quot; ordine n. 12345" è molto più facile da leggere al telefono rispetto a un UUID da 36 caratteri. Su una singola scatola senza sharding, l'auto-incremento è davvero la scelta più semplice e veloce: don' t raggiungere gli UUID fuori moda.

passare a UUID quando ognuno di questi è vero: tu'ridistribuito (più servizi o server che coniano ID in modo indipendente), tu' sei preoccupato per l'enumerazione (gli ID di incremento automatico sono indovinabili e rivelano silenziosamente il conteggio dei tuoi record - /users/1234 Indica a un utente malintenzionato che hai meno di 1.235 utenti), devi unire i dati da più database senza collisioni o vuoi che i client generino ID prima della sincronizzazione. Quel punto di enumerazione è una vera considerazione per la sicurezza delle persone sottovalutate.

e la via di mezzo V7: UUID V7 ti dà la generazione distribuita di un UUID e L'ordinamento indicizzato di auto-incremento, senza far perdere conteggi di record. Per la maggior parte dei nuovi progetti nel 2026 che necessitano di ID non sequenziali, V7 è la risposta che pone fine al dibattito.

Come si archiviano gli UUID senza distruggere il tuo indice?

Questa è la sezione nata dal mio costoso errore, quindi presta attenzione qui se in nessun altro posto.

Su quella migrazione che ho menzionato, ho memorizzato i nuovi UUID come VARCHAR(36) perché era la cosa ovvia e leggibile da fare Funzionava - e poi la tabella cresceva, e gli inserti e i join diventavano misurabilmente più lenti Due problemi si aggravavano: stavo spendendo 36 byte per ID invece di 16, e Stavo usando UUID V4 casuali, quindi ogni insert è atterrato in un punto casuale nell'indice della chiave primaria, frammentandolo e distruendo il pool di buffer. La correzione li memorizzava come binarie e, sul progetto successivo, passando a V7, quindi gli inserti sono rimasti sequenziali.

Postgresql ha un nativo uuid digita - usalo Memorizza 16 byte e confronta velocemente:

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 non ha un tipo UUID nativo, quindi memorizza BINARY(16) e convertire con UUID_TO_BIN() / BIN_TO_UUID(). Il secondo argomento è importante:

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;

La regola da ricordare: nativo uuid digita dove ne hai uno, BINARY(16) Dove non lo fai, e VARCHAR(36) Fondamentalmente mai per una chiave indicizzare e unirsi.

Come si generano gli uuid nel codice?

Per un veloce one-off, il Generatore di UUID è più veloce che aprire un repl. Nel codice, ogni lingua principale ha questo integrato o un passo.

javascript / dattiloscritto- il browser e Node spediscono entrambi un generatore v4 adesso:

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

Pitone:

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

Giava: UUID.randomUUID() ti dà v4 pronto all'uso; v7 ha bisogno di una libreria come java-uuid-generator o una piccola implementazione RFC 9562.

ANDARE: github.com/google/uuid ti dà entrambi - uuid.New() per v4 e uuid.NewV7() per V7.

Nota che gli helper nativi di runtime ti danno quasi sempre v4. Se desideri specificamente V7 per il suo ordine, di solito hai bisogno di una libreria, poiché è lo standard più recente e non tutti gli stdlib hanno raggiunto.

Dove vengono effettivamente visualizzati gli UUID nei sistemi reali?

È facile parlare di UUID in astratto, quindi ecco i luoghi concreti su cui ho fatto affidamento su di essi, perché la versione che scegli dipende davvero dal lavoro.

Chiavi primarie del database in una configurazione distribuita. Questo è il caso classico e quello che ha dato inizio a questo articolo per me Nel momento in cui più di uno scrittore può inserire nella stessa tabella logica - repliche, frammenti o due servizi che condividono uno schema - interruzioni di auto-incremento Una chiave primaria v7 risolve il problema di coordinamento e indicizza ancora in modo pulito perché it's è ordinato nel tempo.

ID generati dal client per app offline. Un'app mobile o un browser SPA spesso ha bisogno di creare un record prima di poter parlare con il server - pensa a una nota scritta su un aereo, o a un'interfaccia utente ottimistica che mostra la nuova riga istantaneamente Se il client attiva un UUID in anticipo, il record ha un'identità stabile dalla prima sequenza di tasti e si sincronizza successivamente senza un viaggio di andata e ritorno del server su & quot; ottieni un ID." I' l'ho usato per far sembrare istantanei i moduli anche su connessioni traballanti.

Identificatori di risorse non enumerabili in URL e API. messa /orders/1042 In un URL dice tranquillamente a chiunque che hai avuto al massimo 1.042 ordini e li lascia camminare /orders/1041, /orders/1040, e così via. Lo scambio in un UUID rimuove sia la perdita di business metrica che la facile enumerazione. Per qualsiasi cosa un utente possa vedere in un URL, vale la pena farlo, anche se ricorda che un UUID non è un meccanismo di controllo degli accessi; dietro c'è ancora bisogno di veri controlli di autorizzazione.

ID di correlazione per la traccia. Quando una singola richiesta si estende su cinque microservizi, allegando un UUID come ID di correlazione e registrandolo ad ogni salto gira & quot; da qualche parte in questo pasticcio qualcosa non è riuscito" in un'unica stringa greppable su tutti i tuoi registri Questo è un posto dove anche una semplice v4 è perfetta: non hai bisogno di ordinare, solo unicità.

chiavi di idempotenza. Le API di pagamento e webhook spesso chiedono al cliente di inviare un UUID come chiave di idempotenza in modo che una richiesta riprovata non addebiti due volte una carta. Il client lo genera una volta, lo riutilizza nei tentativi e il server lo deduce. È un piccolo modello che impedisce una classe molto costosa di bug.

Domande frequenti

A cosa serve un UUID?

Un UUID identifica in modo univoco qualcosa - una riga di database, una risorsa API, una sessione, un file caricato, una traccia attraverso i microservizi - senza bisogno di un servizio centrale per distribuire gli ID. It' è il punto di riferimento ogni volta che più sistemi o client devono creare identificatori in modo indipendente ed essere comunque sicuri che abbiano vinto' t clash. Puoi generarne uno istantaneamente con il Generatore di UUID Su Toolz.dev.

Due UUID possono mai essere identici?

In teoria sì; in pratica no. Un UUID V4 ha 122 bit casuali, che danno circa 5,3 possibilità indecise. Dovresti generare nell'ordine di 2,7 quintilioni di UUID prima di raggiungere una probabilità del 50% anche di una collisione. Per ogni vero scopo di ingegneria, puoi trattare gli UUID come unici garantiti.

Quale versione UUID dovrei usare nel 2026?

Per le nuove chiavi primarie del database, UUID v7 - it's ordinate in base al tempo per un'indicizzazione efficiente pur rimanendo globalmente uniche, e it's l'attuale raccomandazione IETF sotto RFC 9562 Usa v4 quando l'imprevedibilità è importante, come gli identificatori che non devono essere indovinabili Evita v1 per nuovi lavori perché incorpora la macchina generatrice's Indirizzo MAC.

Gli UUID sono sequenziali?

v1 e v7 sono ordinati nel tempo, quindi gli ID generati successivamente ordinano dopo quelli precedenti; v4 è completamente casuale senza ordine L'ordinamento sequenziale è ciò che rende v7 amichevole agli indici B-tree: nuove righe vengono aggiunte anziché disperse Se tu' utilizzi v4 casuale come chiave primaria su una tabella di grandi dimensioni, tale mancanza di ordine può danneggiare le prestazioni di inserimento e indice.

Come devo archiviare gli UUID in un database?

Usa il nativo uuid Digita se il tuo database ne ha uno (postgreSQL lo fa). altrimenti memorizzare BINARY(16), e in MySQL 8.0+ convertire con UUID_TO_BIN() e BIN_TO_UUID(). scansare VARCHAR(36) oppure CHAR(36) per le chiavi: l'archiviazione delle stringhe spreca 20 byte per riga e rallenta ogni confronto, il che si somma rapidamente su tabelle grandi.

Qual è la differenza tra un UUID e un GUID?

Sono la stessa cosa. UUID è il termine RFC 4122 utilizzato nella maggior parte delle lingue e delle piattaforme; GUID è il nome di Microsoft per esso, comune in Windows e .NET. Il formato e le garanzie sono identici, quindi puoi trattare un GUID e un UUID in modo intercambiabile.

Posso estrarre il tempo di creazione da un UUID?

Da v1, v6 e v7, sì, codificano un timestamp. v7 memorizza un timestamp Unix millisecondo nei suoi primi 48 bit, che puoi decodificare e leggere con il Convertitore di timestamp. V4 e V5 non contengono informazioni sul tempo, quindi non c'è nulla da estrarre da esse.

L'UUID v4 è abbastanza sicuro per i token di sessione?

non da solo. I 122 bit casuali di V4 sono imprevedibili, ma i token di sessione e di autenticazione generalmente vogliono almeno 256 bit da un generatore crittograficamente sicuro. Utilizza un token casuale sicuro appositamente creato per l'autenticazione e riserva gli UUID per identificare le risorse anziché proteggerle.

Come faccio a generare un UUID?

Usa il generatore integrato della tua lingua: crypto.randomUUID() Nei browser moderni e Node.js, uuid.uuid4() in Python, o Guid.NewGuid() In .NET ciascuno produce un UUID V4 in una singola chiamata. Per una rapida o una tantum, generarli istantaneamente con il Generatore di UUID su Toolz.dev - nessun codice richiesto.

Quanti caratteri è un UUID?

Un UUID è di 36 caratteri nella sua forma di testo canonico: 32 cifre esadecimali più i quattro trattini che lo dividono in 8-4-4-4-12 gruppi. Quel testo codifica 128 bit, motivo per cui archiviarlo come 16 byte grezzi con BINARY(16) è molto più compatto della stringa di 36 caratteri.

incasso

Gli UUID sono uno di quei fondamenti a cui fai & #39; t pensare fino a quando un sistema cresce oltre un singolo database - e poi loro & #39; sono tutto La versione breve del 2026: predefinita v7 Per le nuove chiavi primarie, utilizzare v4 Quando hai bisogno di ID indiscutibili, conservali come natio uuid oppure BINARY(16), e salta v1 per qualsiasi cosa nuova. Impara dal mio VARCHAR(36) pomeriggio quindi non lo ripeto.

generarli istantaneamente con il libero Generatore di UUID su Toolz.dev - singolo o in blocco, qualsiasi versione, tutto lato client senza nulla caricato Quando hai bisogno di leggere l'ora all'interno di una v7, raggiungi il Convertitore di timestamp, e sfoglia il resto del Strumenti di codifica- Oltre 600 utenze gratuite - oltre a Toolz.dev.