uuid_short() producerer en bitvis konglomeration af server-id'et, en ret statisk tidskomponent og et sekventielt stigende 24 bit heltal. Disse bits er fyldt ind i et 8 byte heltal. Tidskomponenten er baseret på serverens opstartstid.
uuid() producerer hex-streng, der repræsenterer en 16 byte version1 UUID. Version 1 UUID'er er en bitvis konglomeration af server-id'et, det aktuelle tidsstempel, et par bytes, der kommer i spil, hvis du genererer id'er med høj hastighed, og et par hjælpebits.
For at besvare dit spørgsmål:gør uuid_short give tid og rum unikhed, der konkurrerer med uuid ? Svaret er nej. Eksempelvis server-id'et i en uuid_short er kun én byte. Så hvis du har 256 eller flere servere, vil i det mindste nogle få af dem have det samme node-id, hvilket betyder, at du mister pladsens unikke karakter. Til sammenligning er server-id'et i version 1 UUID 6 bytes langt, hvilket effektivt dræber chancen for dubletter for alle undtagen de største af virksomhedens serverfarme :)
Et bedre spørgsmål er, om uuid_short er god nok. Du kan se ID-kollisioner, hvis du:
- Generer mere end 16 millioner IDS fra den samme server på kort tid. ***
- Start servere med det samme server-id på nøjagtig samme tid, og del data mellem dem.
- Filer med systemuret, og genstart derefter din server.
Det andet problem virker usandsynligt for de fleste mennesker, men det første er værd at undersøge, før du forpligter dig til at lave uuid_short grundlaget for dine nøgler.
*** Baseret på mysql-dokumenterne for uuid_short , det ser ud til, at du ville se kollisioner, hvis du genererede mere end 16 millioner ID'er i løbet af en enkelt servers oppetid. Men det ville være dumt. MySQL-dokumenterne fortsætter med at sige, at du har det fint, så længe du ikke genererer 16 millioner ID'er i sekundet. Det betyder, at de skal støde nogle af bits i tidsstemplet, hvis du udtømmer de 16 millioner sekventielle ID'er. Jeg har ikke testet dette.