Mi sono imbattuto in questo stesso problema nella mia vita professionale. Abbiamo utilizzato timestamp + numero casuale e abbiamo riscontrato seri problemi quando le nostre applicazioni sono aumentate (più client, più server, più richieste). Certo, noi (stupidamente) abbiamo usato solo 4 cifre, per poi passare a 6, ma saresti sorpreso dalla frequenza con cui gli errori si verificano ancora.
Per un periodo di tempo sufficientemente lungo, sei garantito per ottenere errori di chiave duplicati. La nostra applicazione è mission-critical, e quindi anche la minima possibilità che potesse fallire a causa di un comportamento intrinsecamente casuale era inaccettabile. Abbiamo iniziato a utilizzare gli UUID per evitare questo problema e ne abbiamo gestito con cura la creazione.
Utilizzando gli UUID, la dimensione dell'indice aumenterà e un indice più grande comporterà prestazioni inferiori (forse impercettibili, ma comunque inferiori). Tuttavia MySQL supporta un tipo UUID nativo (non usare mai varchar come chiave primaria!!) e può gestire l'indicizzazione, la ricerca, ecc. in modo dannatamente efficiente anche rispetto a bigint. Il maggiore impatto sulle prestazioni del tuo indice è quasi sempre il numero di righe indicizzate, piuttosto che la dimensione dell'elemento da indicizzare (a meno che tu non voglia indicizzare su un testo lungo o qualcosa di ridicolo del genere).
Per rispondere alla tua domanda:Bigint (con numeri casuali allegati) andrà bene se non prevedi di ridimensionare in modo significativo la tua applicazione/servizio. Se il tuo codice è in grado di gestire la modifica senza troppe modifiche e la tua applicazione non esploderà se si verifica un errore di chiave duplicata, seguilo. Altrimenti, mordi il proiettile e scegli l'opzione più sostanziosa.
Puoi sempre implementare una modifica più ampia in un secondo momento, come passare a un backend completamente diverso (che ora stiamo affrontando... :P)
