S tímto problémem jsem se setkal ve svém profesním životě. Použili jsme časové razítko + náhodné číslo a při zvětšování našich aplikací jsme narazili na vážné problémy (více klientů, více serverů, více požadavků). Je pravda, že jsme (hloupě) použili pouze 4 číslice a pak jsme je změnili na 6, ale byli byste překvapeni, jak často se chyby stále vyskytují.
Po dostatečně dlouhou dobu máte záruku získat duplicitní klíčové chyby. Naše aplikace je kritická, a proto i sebemenší šance, že by mohla selhat kvůli inherentně náhodnému chování, byla nepřijatelná. Abychom se tomuto problému vyhnuli, začali jsme používat UUID a pečlivě jsme spravovali jejich vytváření.
Pomocí UUID se velikost vašeho indexu zvětší a větší index bude mít za následek horší výkon (možná nepozorovatelný, ale přesto horší). MySQL však podporuje nativní typ UUID (nikdy nepoužívejte varchar jako primární klíč!!) a zvládne indexování, vyhledávání atd. zatraceně efektivně, dokonce i ve srovnání s bigintem. Největším zásahem do výkonu vašeho indexu je téměř vždy počet indexovaných řádků, spíše než velikost indexované položky (pokud nechcete indexovat dlouhý text nebo něco podobného).
Abych odpověděl na vaši otázku:Bigint (s připojenými náhodnými čísly) bude v pořádku, pokud neplánujete výrazně škálovat vaši aplikaci/službu. Pokud váš kód zvládne změnu bez velkých změn a vaše aplikace nevybuchne, pokud dojde k chybě duplicitního klíče, pokračujte. V opačném případě se pusťte do toho a jděte na podstatnější možnost.
Vždy můžete později implementovat větší změnu, jako je přechod na úplně jiný backend (kterému nyní čelíme... :P)