1. A Armadilha do UUID v4 em Bancos de Dados
O UUID v4 (RFC 4122) tornou-se extremamente popular na última década por gerar 122 bits de pura entropia aleatória via crypto.randomUUID(). Essa aleatoriedade garante uma probabilidade de colisão estatisticamente nula em sistemas distribuídos.
No entanto, ao utilizar UUID v4 como Chave Primária (PRIMARY KEY) em bancos de dados como PostgreSQL, MySQL (InnoDB) ou SQL Server, surge um problema silencioso: a fragmentação catastrófica de índices B-Tree.
Como o UUID v4 é 100% aleatório, cada nova inserção (INSERT) precisa ser gravada em páginas de disco arbitrárias do índice. Isso causa constantes divisões de página (page splits), explosão do consumo de memória RAM do pool de buffers e aumento drástico no tempo de escrita.
2. Como o UUID v7 Resolve a Fragmentação
A RFC 9562 introduziu o UUID v7, que combina o melhor dos dois mundos:
- Primeiros 48 bits: Timestamp UNIX em milissegundos (garantindo que novas chaves sejam sempre sequencialmente crescentes).
- 16 bits centrais: Versão (
0111) e contador de sub-milissegundo para ordenação perfeita em alta concorrência. - 62 bits finais: Entropia puramente criptográfica (variante RFC e dados aleatórios para garantir unicidade global).
Em benchmarks práticos de inserção contínua de 10 milhões de registros no PostgreSQL, tabelas utilizando UUID v7 apresentaram escritas até 40% mais rápidas e índices 30% menores em comparação com UUID v4.