UUID v4 vs v7: que identificador único escolher?

Um UUID é um identificador de 128 bits único sem coordenação central. A versão 4, totalmente aleatória, domina há anos. A versão 7, mais recente (RFC 9562, 2024), integra um carimbo temporal no início para produzir identificadores ordenados no tempo. Esta diferença, aparentemente inócua, altera radicalmente o desempenho na base de dados. Eis qual escolher.

O que é um UUID?

Um UUID (Universally Unique Identifier) é um número de 128 bits representado por 32 caracteres hexadecimais agrupados em cinco blocos, por exemplo 550e8400-e29b-41d4-a716-446655440000. A sua razão de ser: gerar um identificador único sem pedir a uma autoridade central, o que o torna ideal para os sistemas distribuídos. Pode gerar alguns com o nosso gerador de UUID.

Existem várias versões; as mais pertinentes hoje para chaves de registo são a v4 (aleatória) e a v7 (ordenada no tempo).

UUID v4 (aleatório)

O UUID v4 é constituído por 122 bits aleatórios (o resto codifica a versão e o variant). A probabilidade de colisão é tão reduzida que é negligenciável na prática. É a versão por omissão na maioria das linguagens e bibliotecas.

• Imprevisível: perfeito para tokens ou identificadores públicos que não se querem adivinháveis
• Nenhuma fuga de informação: não revela data nem ordem de criação
• Inconveniente: totalmente desordenado, o que maltrata os índices de base de dados

UUID v7 (ordenado no tempo)

O UUID v7 coloca um carimbo temporal Unix em milissegundos nos seus primeiros 48 bits, seguido de bits aleatórios. Dois UUID v7 gerados em instantes diferentes ordenam-se assim pela ordem da sua criação, mantendo-se únicos e praticamente impossíveis de adivinhar.

• Ordenável: a ordem lexicográfica corresponde à ordem cronológica
• Amigável para os índices: as inserções fazem-se no fim do índice, como um auto-incremento
• Contrapartida: revela o instante de criação, o que pode ser indesejável para um identificador público

Tabela comparativa

Impacto nas bases de dados

É o cerne do assunto. As bases relacionais armazenam os seus índices em árvores B (B-tree). Inserir chaves aleatórias (v4) dispersa as escritas por todo o índice, provocando fragmentação, divisões de páginas e uma cache menos eficaz. Em grandes volumes, o desempenho de inserção degrada-se nitidamente.

As chaves ordenadas (v7) inserem-se sempre no fim do índice, como um identificador auto-incrementado. Recuperam-se inserções rápidas, melhor localidade e um índice mais compacto. É particularmente nítido com uma chave primária em InnoDB (MySQL), em que a chave primária determina a ordem física das linhas.

Quando escolher um ou outro

Escolher UUID v4 quando

• O identificador é exposto publicamente e não deve revelar nada
• Gera tokens, ligações de partilha, segredos
• A ordem e a data de criação não devem ser adivinháveis
• Pretende uma compatibilidade máxima com o existente

Escolher UUID v7 quando

• O UUID serve de chave primária numa base de dados
• O volume de inserções é elevado e o desempenho de índice conta
• Pretende ordenar por ordem de criação sem coluna dedicada
• Revelar o instante de criação não é um problema

Recomendação

Para uma chave primária de base de dados, prefira doravante UUID v7: mantém a unicidade distribuída do UUID evitando a penalização de índice da v4. Conserve UUID v4 para os identificadores públicos, tokens e segredos, em que a imprevisibilidade total e a ausência de fuga temporal prevalecem.

Verifique ainda assim o suporte da v7 na sua linguagem e no seu ORM: a RFC é recente, mas a adoção progride depressa.

Perguntas frequentes