UUID v4 vs v7 nel 2026: layout dei bit, ordinamento, costo dell'indice

Ogni UUID è di 16 byte, e i campi sono definiti per posizione, non dai trattini del testo. Il byte 6 contiene la versione nel suo nibble alto. Il byte 8 contiene la variante nei suoi due bit più alti. Tutto il resto dipende dalla versione. Nella stringa canonica, il 13° carattere esadecimale è la versione e il 17° è la variante.

Per v4, i 122 bit che non sono versione o variante sono casuali. Per v7, i primi 48 bit sono il timestamp Unix in millisecondi, big-endian, ed è per questo che i valori v7 si ordinano per data di creazione come byte grezzi. I restanti 74 bit sono casuali per impostazione predefinita, anche se la RFC 9562 consente ad alcuni di essi di portare un contatore per la monotonicità all'interno di un millisecondo.

Un UUID v4 è un numero casuale con sei bit fissi. Il nibble alto del byte 6 è 0100, quindi il 13° carattere della stringa canonica è sempre 4. I due bit più alti del byte 8 sono 10, quindi il 17° carattere è sempre 8, 9, a o b. Questi sono gli unici caratteri prevedibili; gli altri 30 caratteri esadecimali sono casuali.

La casualità è la proprietà di sicurezza. Un valore v4 non porta timestamp, sequenza né identificatore di macchina, quindi non rivela nulla su quando o dove è stato creato. Questo lo rende una scelta ragionevole per un identificatore pubblico che non deve essere enumerabile, a condizione che sia generato da una sorgente casuale crittograficamente sicura. Uno spazio di 122 bit rende le collisioni trascurabili: un miliardo di valori dà una probabilità di collisione di circa 2^-63.

Un UUID v7 è ordinato nel tempo. I byte da 0 a 5 contengono il numero di millisecondi dall'epoca Unix, big-endian. Il nibble alto del byte 6 è 0111. Il nibble basso del byte 6 e tutto il byte 7 formano rand_a, i due bit più alti del byte 8 sono la variante, e i restanti 62 bit sono rand_b. Sono 74 bit casuali più un timestamp leggibile a colpo d'occhio.

Il timestamp è di 48 bit, sufficienti per i millisecondi fino all'anno 10889, quindi l'overflow non è un problema pratico. Due valori v7 creati nello stesso millisecondo differiscono solo nei loro bit casuali o di contatore, e un valore creato dopo si confronta sempre come maggiore, come stringa di byte, rispetto a uno creato prima, purché l'orologio non torni indietro. Quell'ordinamento è tutto il punto.

L'ordinamento lessicografico del testo canonico corrisponde all'ordine dei byte, perché i trattini stanno in posizioni fisse e le cifre esadecimali si ordinano nello stesso ordine dei loro valori quando sono minuscole. Ordina per la forma testuale o per i 16 byte e ottieni l'ordine di creazione. Questo vale tra macchine senza coordinamento, ed è per questo che v7 è attraente per i log degli eventi e per gli identificatori che diventano parte di una chiave di ordinamento.

Il divario è all'interno di un singolo millisecondo. Per impostazione predefinita, due valori creati nello stesso millisecondo sono ordinati dai loro bit casuali, che non è l'ordine di creazione. La RFC 9562 descrive l'uso del campo rand_a, o dei bit casuali più a sinistra, come contatore inizializzato casualmente a ogni scatto del timestamp. Con quel metodo, i valori sono monotoni ai fini pratici all'interno di un millisecondo, al costo di un po' meno casualità e di un contatore condiviso che i produttori concorrenti devono gestire con attenzione.

Una chiave primaria v4 casuale si inserisce in una posizione casuale dell'indice. Su un B-tree questo significa toccare una pagina foglia diversa quasi a ogni inserimento, espellere pagine dal buffer pool e dividere le pagine a metà, lasciandole semivuote. L'indice cresce, la write amplification aumenta e i tassi di cache hit calano man mano che la tabella cresce.

Una chiave v7 si inserisce vicino al bordo destro, quindi il working set resta piccolo e le divisioni di pagina avvengono alla fine, dove costano poco. Il compromesso è la contesa: ogni scrittore vuole la stessa pagina più a destra. Su un singolo database di solito va bene con qualche centinaio di scritture al secondo; a concorrenza molto alta diventa un hotspot, e le mitigazioni abituali sono il batching, l'interleaving a livello di connessione o un po' di jitter nei bit alti.

Un valore v7 dice a chiunque lo possieda all'incirca quando è stato creato, al millisecondo, e quindi quanti altri record sono stati creati in quel periodo. Va bene per chiavi interne e id di eventi. Non va bene per un identificatore pubblico che non deve rivelare il volume di iscrizioni, il tasso di ordini o l'età di un account.

Se hai bisogno sia di ordinamento che di opacità, le opzioni sono tenere v7 interno ed esporre un id pubblico casuale separato, oppure usare v4 per qualsiasi cosa che esca dal tuo sistema. Non trattare un UUID come token di capacità in nessuna delle due versioni; entrambi sono identificatori, non autorizzazioni. Un id v4 è impraticabile da indovinare, ma va comunque verificato contro il controllo degli accessi a ogni richiesta.

Sedici byte è la risposta di archiviazione per entrambe le versioni. La forma testuale canonica è di 36 caratteri, di cui 32 cifre esadecimali e 4 trattini. Archiviare la forma testuale raddoppia la dimensione e rallenta i confronti, quindi usa un tipo UUID nativo dove esiste, BINARY(16) dove non esiste, e formatta solo al confine.

SQL Server ha una particolarità che vale la pena testare: il suo tipo uniqueidentifier si ordina in un ordine di byte diverso dalla stringa canonica, e l'ordine interno dei byte differisce dalla RFC 4122. Il codice che si basa sull'ordinamento v7 deve verificare il comportamento dell'ordinamento su quella piattaforma invece di darlo per scontato. Dove serve una forma testuale compatta, base64url senza padding dà 22 caratteri, ma non è una rappresentazione UUID standard e confonderà gli strumenti che si aspettano la forma canonica.

Scegli v7 quando l'identificatore è una chiave di database, quando vuoi ordinare per data di creazione senza una seconda colonna o quando stai costruendo una tabella a prevalenza di append. Scegli v4 quando il valore è esposto pubblicamente, quando la data di creazione è sensibile o quando il sistema archivia già una colonna timestamp e non guadagna nulla dall'ordinamento. Entrambe sono scelte corrette per vincoli diversi, e mescolarle in una tabella è di solito un errore.

I test devono verificare la struttura, non i valori. Controlla il nibble di versione, il nibble di variante e la lunghezza in byte dopo il parsing. Per v7, verifica che il timestamp incorporato cada nella finestra del test e che due valori creati in ordine si confrontino correttamente. Non fare mai snapshot di un UUID letterale in un test, e non verificare mai che un v7 sia strettamente maggiore del precedente a meno che il generatore non usi un contatore; senza contatore, l'ordine nello stesso millisecondo è casuale.