As diferenças entre INT e UUID no MySQL

UUID retorna um identificador exclusivo universal (espero que também seja exclusivo se importado para outro banco de dados também).

Para citar o doc do MySQL (ênfase minha):

Por outro lado, um simples INT chave de ID primária (por exemplo, AUTO_INCREMENT ) retornará um inteiro único para o banco de dados específico e a tabela de banco de dados, mas que não é universalmente exclusivo (portanto, se importado para outro banco de dados, provavelmente haverá conflitos de chave primária).

Em termos de desempenho, não deve haver nenhuma diferença perceptível usando auto-increment sobre UUID . A maioria dos posts (incluindo alguns dos autores deste site), declaram como tal. Claro UUID pode levar um pouco mais de tempo (e espaço), mas isso não é um gargalo de desempenho para a maioria (se não todos) os casos. Ter uma coluna como Primary Key deve fazer ambas as escolhas iguais em relação ao desempenho. Veja referências abaixo:

(UUID vs auto-increment resultados de desempenho, adaptados de Mitos, GUID vs Autoincrement )

UUID prós / contras (adaptado de Chaves primárias:ID s versus GUID s )

Observação

Eu leria atentamente as referências mencionadas e decidiria se usaria UUID ou não dependendo do meu caso de uso. Dito isso, em muitos casos UUID s seria realmente preferível. Por exemplo, pode-se gerar UUID s sem usar/acessar o banco de dados, ou mesmo usar UUID s que foram pré-computados e/ou armazenados em outro lugar. Além disso, você pode facilmente generalizar/atualizar seu esquema de banco de dados e/ou esquema de cluster sem ter que se preocupar com ID está quebrando e causando conflitos.

Em termos de possíveis colisões, por exemplo, usando UUIDS v4 (aleatório), a probabilidade de encontrar uma duplicata em 103 trilhões de UUIDs da versão 4 é um em um bilhão.