uuid_short() produce un conglomerato bit per bit dell'ID del server, una componente temporale abbastanza statica e un intero a 24 bit che aumenta in sequenza. Questi bit vengono inseriti in un numero intero di 8 byte. La componente temporale si basa sull'ora di avvio del server.
uuid() produce una stringa esadecimale che rappresenta un UUID version1 a 16 byte. Gli UUID della versione 1 sono un conglomerato bit per bit dell'ID del server, il timestamp corrente, alcuni byte che entrano in gioco se si generano ID a velocità ipertestuale e alcuni bit di utilità.
Per rispondere alla tua domanda:fa uuid_short fornire un'unicità di tempo e spazio che rivaleggia con uuid ? La risposta è no. Caso in questione, l'ID del server in un uuid_short è solo un byte. Quindi, se hai 256 o più server, almeno alcuni di essi avranno lo stesso ID nodo, il che significa che perdi l'unicità dello spazio. Per fare un confronto, l'ID del server nell'UUID della versione 1 è lungo 6 byte, eliminando di fatto la possibilità di duplicati per tutte le server farm aziendali tranne le più grandi :)
Una domanda migliore è se uuid_short è abbastanza buono. Potresti vedere le collisioni di ID se :
- Genera più di 16 milioni di IDS dallo stesso server in poco tempo. ***
- Avvia i server con lo stesso ID server tutti esattamente nello stesso momento e condividi i dati tra di loro.
- Giocare con l'orologio di sistema e quindi riavviare il server.
Il secondo problema sembra improbabile per la maggior parte delle persone, ma vale la pena indagare sul primo prima di impegnarti a creare uuid_short la base delle tue chiavi.
*** Basato sui documenti mysql per uuid_short , sembra che tu possa vedere delle collisioni se generassi più di 16 milioni di ID durante il tempo di attività di un singolo server. Ma sarebbe sciocco. I documenti mysql continuano dicendo che stai bene purché non generi 16 milioni di ID al secondo. Ciò implica che devono aumentare alcuni bit nel timestamp se si esauriscono i 16 milioni di ID sequenziali. Non l'ho testato.
