Configurações
5
Clique em Gerar...

UUID: o identificador universal que todo desenvolvedor precisa conhecer

O UUID (Universally Unique Identifier) é um identificador padronizado de 128 bits definido pela RFC 4122. É representado como uma string hexadecimal no formato xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx com exatamente 36 caracteres (32 hexadecimais + 4 hífens). A probabilidade de dois UUIDs v4 serem iguais é astronomicamente baixa: 1 em 2^122 (cerca de 5,3 × 10^36).

Versões de UUID: qual usar em cada situação

Versão Base Ordenável? Uso recomendado
v1 Timestamp + MAC Sim (tempo) Logs, auditoria — mas expõe o endereço MAC
v3 MD5 + namespace Não Identificadores determinísticos (mesmo input = mesmo UUID)
v4 Aleatório Não Chave primária, tokens, IDs de sessão — uso geral
v5 SHA-1 + namespace Não Melhor que v3, mesmo princípio determinístico
v6 Timestamp (reorganizado) Sim Banco de dados com índice — melhor que v1
v7 Timestamp Unix Sim Novo padrão recomendado para PKs em banco

UUID vs ULID vs NanoID: qual identificador escolher?

O UUID v4 é o padrão mais estabelecido, mas alternativas modernas têm vantagens específicas. O ULID (Universally Unique Lexicographically Sortable Identifier) combina timestamp com aleatoriedade, sendo ordenável cronologicamente — excelente para chaves primárias em bancos relacionais onde a ordenação importa para o índice B-tree. O NanoID é uma alternativa menor (21 chars por padrão) e mais URL-friendly. O UUID v4 permanece a escolha mais segura e universalmente suportada para a maioria dos casos.

Impacto do UUID como chave primária no desempenho do banco

UUID v4 como PK em bancos relacionais tem um problema conhecido: a aleatoriedade causa fragmentação de índice B-tree, degradando a performance de INSERT em tabelas grandes. A solução é usar UUIDs ordenáveis (v6, v7 ou ULID) ou armazenar o UUID como BINARY(16) em vez de CHAR(36) para economizar espaço e melhorar comparações.

Perguntas frequentes — Gerador de UUID
Dois UUIDs v4 podem ser iguais?
Teoricamente sim, mas a probabilidade é de 1 em 5,3 × 10^36. Para colocar em perspectiva: você precisaria gerar 1 bilhão de UUIDs por segundo durante 85 anos para ter 50% de chance de uma colisão. Na prática, considere-os únicos.
Como gerar UUID em Node.js sem biblioteca?
Use a API nativa: const uuid = crypto.randomUUID(); Disponível no Node.js 14.17+. Para versões anteriores: const { v4: uuidv4 } = require('uuid'); e npm install uuid.
Como armazenar UUID no MySQL de forma eficiente?
Use BINARY(16) em vez de CHAR(36): INSERT INTO tabela (id) VALUES (UUID_TO_BIN(UUID(), TRUE)). O TRUE ativa o swap de bytes para melhorar a ordenação. Para recuperar: SELECT BIN_TO_UUID(id, TRUE) AS id FROM tabela.
UUID é adequado para tokens de sessão e autenticação?
Sim, UUID v4 é adequado para tokens de sessão. Para tokens de autenticação mais críticos (reset de senha, API keys), considere gerar bytes aleatórios maiores (256 bits) usando crypto.randomBytes(32).toString('hex') no Node.js, resultando em um token hexadecimal de 64 caracteres.
Qual a diferença entre UUID e GUID?
GUID (Globally Unique Identifier) é o nome usado pela Microsoft para o mesmo padrão UUID definido na RFC 4122. São equivalentes. A diferença é apenas terminológica — GUID é o termo do ecossistema Windows/.NET, UUID é o termo IETF/Unix/Linux.
Como comparar UUIDs em SQL de forma eficiente?
Armazene como BINARY(16) e compare com operadores binários. Para PostgreSQL, use o tipo nativo UUID que ocupa 16 bytes internamente mas exibe como string. Evite comparações LIKE ou UPPER() em UUIDs armazenados como VARCHAR.
UUID v4 pode ser previsível em alguma situação?
Se gerado com Math.random() (não recomendado), sim. Nossa ferramenta usa crypto.randomUUID() que usa o CSPRNG do sistema operacional. Em Node.js e browsers modernos, a implementação é criptograficamente segura. Em ambientes sem CSPRNG adequado (IoT, sistemas embarcados antigos), verifique a qualidade do gerador de entropia.
Quando devo usar UUID v7 em vez de UUID v4?
Use UUID v7 quando precisar de IDs sequencialmente ordenáveis por tempo de criação — essencial para PKs em bancos relacionais com índices B-tree, pois inserts sequenciais são muito mais eficientes. Use UUID v4 quando a ordenação não importa, em sistemas NoSQL ou quando a compatibilidade com sistemas legados é necessária.