Resposta rápida Uma UUID v4 é 100% aleatória, por isso cada nova linha insere-se numa posição imprevisível do índice — o que pode fragmentar páginas em bases de dados muito grandes. Uma UUID v7 resolve isto ao guardar uma marca temporal nos primeiros 48 bits, ficando ordenada cronologicamente como um ID autoincrementado.
Um número autoincrementado é sempre inserido no final do índice — é a inserção mais "barata" possível para a maioria dos motores de base de dados. Uma UUID v4 salta para qualquer posição do intervalo de 128 bits, o que obriga o motor a reorganizar páginas de índice com mais frequência. A UUID v7 combina o melhor dos dois: os primeiros bits (a marca temporal) garantem que valores gerados em sequência ficam próximos uns dos outros no índice, tal como acontece com um autoincrementado, mas sem depender de um único contador central.
Nota prática: se a tua aplicação já usa UUID v4 e não sentes problemas de desempenho, não há razão para migrar. A diferença só costuma ser mensurável em tabelas com dezenas de milhões de linhas e muita escrita concorrente.
Segurança: o que um ID sequencial revela
Resposta rápida Um ID autoincrementado exposto num URL público (ex. /pedidos/4821) revela quantos registos existem e permite tentar adivinhar outros IDs vizinhos. Uma UUID aleatória não permite essa dedução.
Considera um cenário simples: uma aplicação de faturas usa /faturas/1042 como URL. Um utilizador curioso percebe imediatamente o padrão e tenta /faturas/1041 ou /faturas/1043. Se o servidor não verificar corretamente a quem pertence cada fatura, este é o clássico problema de segurança chamado IDOR (Insecure Direct Object Reference). Com uma UUID como 7b2e1c9a-4f31-4d02-9a7e-1d4c5e8f2a10, não há sequência para adivinhar — o controlo de acesso continua a ser necessário, mas o ID em si já não facilita a exploração.
Isto não substitui verificações de autorização adequadas no servidor; é apenas uma camada extra que reduz a superfície de ataque mais óbvia.
Quando escolher cada opção
- ID autoincrementado (INT/BIGINT): boa opção para tabelas internas, de tamanho moderado, sem exposição pública direta do ID, e onde a simplicidade e o desempenho de inserção são prioridade.
- UUID v4: boa opção quando os registos são criados por múltiplos sistemas ou dispositivos em simultâneo (sem um contador central) e/ou o ID pode aparecer em URLs públicos.
- UUID v7: boa opção quando queres unicidade distribuída (como v4) mas também ordenação temporal e melhor localidade de índice — normalmente a recomendação atual para novos projetos que hesitam entre v4 e um autoincrementado.
Exemplo ilustrativo: uma equipa que sincroniza pedidos criados offline em várias lojas físicas, antes de existir ligação ao servidor central, precisa de IDs que nunca colidam entre lojas — este é um caso típico onde UUID (v4 ou v7) resolve um problema real que um autoincrementado central não resolveria sozinho.
Perguntas frequentes
UUID ocupa mais espaço do que um número autoincrementado?
Sim. Uma UUID ocupa 128 bits (16 bytes) de dados brutos, enquanto um inteiro autoincrementado típico (BIGINT) ocupa 64 bits (8 bytes) — o dobro do espaço por linha, e por cada índice e chave estrangeira que a referencia. Numa tabela com dezenas de milhões de linhas, isto pode representar vários gigabytes extra de armazenamento e índices maiores, o que é uma diferença real a considerar, ainda que não costume ser decisivo sozinho.
UUID v4 é má escolha para chave primária?
Não é «má», mas tem uma desvantagem prática conhecida: por ser totalmente aleatória, os valores inserem-se em posições dispersas dentro de um índice B-tree, o que pode causar mais fragmentação de página e escrita em disco do que um valor sequencial. Em bases de dados muito grandes ou com muita escrita, isto pode ter impacto de desempenho mensurável. Para a maioria das aplicações de tamanho pequeno a médio, esse impacto costuma ser irrelevante face às vantagens de segurança e de mesclagem entre bases de dados.
O que é uma UUID v7 e porque é recomendada para bases de dados?
Uma UUID v7 tem os primeiros 48 bits reservados a uma marca temporal Unix em milissegundos, seguidos de bits aleatórios. Isto significa que UUID v7 geradas em sequência ficam também ordenadas cronologicamente — tal como um ID autoincrementado —, mas sem revelar quantas linhas existem nem depender de um único contador central. Por isso é hoje a opção normalmente recomendada quando se quer o melhor dos dois mundos: unicidade distribuída e boa localidade de índice.
Um ID autoincrementado revela informação sensível?
Pode revelar. Se um URL público mostra /pedidos/4821, qualquer pessoa consegue inferir que já existem pelo menos 4821 pedidos, e pode tentar aceder a /pedidos/4820 ou /pedidos/4822 para ver registos de outros utilizadores (um problema clássico chamado IDOR — Insecure Direct Object Reference — se o controlo de acesso não for verificado à parte). Uma UUID aleatória não permite essa dedução nem essa enumeração sequencial.
Posso gerar UUID grátis sem instalar nada?
Sim. O Gerador UUID do ToolPico cria UUID v4, v1, v3/v5 e v7 diretamente no navegador, em lotes de até 1000, com opções de formato (maiúsculas/minúsculas, hífens, chavetas .NET, prefixo urn:uuid:) e um validador. Nenhum dado é enviado para um servidor — tudo corre localmente no teu dispositivo.
Nota: este artigo tem fins informativos e educativos sobre boas práticas gerais de bases de dados; não substitui uma análise de desempenho ou de segurança específica do teu sistema. Os números apresentados (tamanhos de tabela, contagens de linhas) são exemplos ilustrativos, não medições reais.