Jag har stött på just detta problem i mitt yrkesliv. Vi använde tidsstämpel + slumptal och stötte på allvarliga problem när våra applikationer skalade upp (fler klienter, fler servrar, fler förfrågningar). Visst, vi använde (dumt nog) bara 4 siffror och ändrade sedan till 6, men du skulle bli förvånad över hur ofta felen fortfarande inträffar.
Under tillräckligt lång tid är du garanterad för att få dubbletter av nyckelfel. Vår applikation är affärskritisk, och därför var även den minsta chansen att den skulle misslyckas på grund av ett naturligt slumpmässigt beteende oacceptabel. Vi började använda UUID för att undvika det här problemet och hanterade noggrant skapandet av dem.
Om du använder UUID kommer din indexstorlek att öka, och ett större index kommer att resultera i sämre prestanda (kanske omärkligt, men sämre ändå). Men MySQL stöder en inbyggd UUID-typ (använd aldrig varchar som primärnyckel!!), och kan hantera indexering, sökning etc ganska jävla effektivt även jämfört med bigint. Den största resultatträffen för ditt index är nästan alltid antalet rader som indexeras, snarare än storleken på objektet som indexeras (såvida du inte vill indexera på en långtext eller något löjligt sådant).
För att svara på din fråga:Bigint (med slumpmässiga siffror bifogade) kommer att vara ok om du inte planerar att skala din applikation/tjänst avsevärt. Om din kod kan hantera ändringen utan större förändringar och din applikation inte kommer att explodera om ett duplicerat nyckelfel uppstår, gå med det. Annars, bita-i-helen och välj det mer omfattande alternativet.
Du kan alltid implementera en större förändring senare, som att byta till en helt annan backend (som vi nu står inför... :P)