uuid_short() produz um conglomerado bit a bit do ID do servidor, um componente de tempo bastante estático e um número inteiro de 24 bits sequencialmente crescente. Esses bits são inseridos em um inteiro de 8 bytes. O componente de tempo é baseado no tempo de inicialização do servidor. uuid() produz uma string hexadecimal que representa um UUID version1 de 16 bytes. Os UUIDs da versão 1 são um conglomerado bit a bit do ID do servidor, o carimbo de data/hora atual, alguns bytes que entram em jogo se você gerar IDs em hipervelocidade e alguns bits de utilitário. Para responder à sua pergunta:
uuid_short fornecer exclusividade de tempo e espaço que rivaliza com uuid ? A resposta é não. Caso em questão, o ID do servidor em um uuid_short é apenas um byte. Portanto, se você tiver 256 ou mais servidores, pelo menos alguns deles terão o mesmo ID de nó, o que significa que você perde a exclusividade do espaço. Para comparação, o ID do servidor na versão 1 UUID tem 6 bytes, eliminando efetivamente a chance de duplicatas para todos, exceto o maior dos farms de servidores corporativos :) Uma pergunta melhor é se
uuid_short é bom o suficiente. Você pode ver colisões de ID se:- Gere mais de 16 milhões de IDS do mesmo servidor em pouco tempo. ***
- Inicie servidores com o mesmo ID de servidor exatamente ao mesmo tempo e compartilhe dados entre eles.
- Mexa com o relógio do sistema e reinicie o servidor.
O segundo problema parece improvável para a maioria das pessoas, mas vale a pena investigar o primeiro antes de você se comprometer a fazer
uuid_short a base de suas chaves. *** Baseado nos documentos do mysql para
uuid_short , parece que você veria colisões se gerasse mais de 16 milhões de IDs durante o tempo de atividade de um único servidor. Mas isso seria bobagem. Os documentos do mysql continuam dizendo que você está bem desde que não gere 16 milhões de IDs por segundo. Isso implica que eles devem aumentar alguns dos bits no registro de data e hora se você esgotar os 16 milhões de IDs sequenciais. Eu não testei isso. 
