v4 ou v7
v4 são 122 bits de puro acaso. O valor não conta quando nem onde foi criado. Serve para identificadores que aparecem em URLs públicas, links de convite e qualquer lugar onde a ordem de criação deva ficar escondida.
v7 coloca um carimbo de tempo em milissegundos nos primeiros 48 bits e preenche o resto com acaso, então ordenar as strings é ordenar por data de criação. Use em chaves primárias, identificadores de log e eventos, onde a cronologia ajuda. Em troca, a hora de criação passa a ser legível no próprio valor: se isso revelar algo, volte para v4.
NIL é o valor só de zeros. Funciona como marcador de “ainda nada” numa coluna que não aceita nulo.
Como chave primária
Usar UUID em vez de um inteiro autoincremental permite que vários servidores gerem chaves sem se coordenar, e um identificador na URL deixa de permitir adivinhar as linhas vizinhas.
O problema é o acaso do v4. Um índice B-tree trabalha melhor quando as chaves novas caem no fim; uma chave v4 cai em qualquer ponto do meio e divide páginas sem parar. Com a tabela crescendo, as escritas ficam lentas e o índice incha. O v7 evita isso porque os valores crescem com o tempo e sempre entram no fim. Para uma tabela nova, v7 é o padrão sensato.
Guarde como BINARY(16) no MySQL ou no tipo uuid do PostgreSQL. Manter a string de 36 caracteres custa 20 bytes a mais por linha e deixa cada comparação mais lenta.
Sem hifens
Os hifens são convenção de exibição, não fazem parte do valor. Nomes de arquivo, códigos de cupom e algumas APIs usam a forma colada de 32 caracteres. Maiúsculas também são só apresentação: antes de comparar dois UUID, passe os dois para minúsculas.
Ao gerar um lote
Quando esta ferramenta produz vários v7 de uma vez, eles mantêm a ordem de geração. Tudo criado dentro do mesmo milissegundo compartilha o carimbo de tempo, o que embaralharia a lista, então parte do campo aleatório vira contador. Copie a lista inteira e a ordenação continua valendo.