Me he encontrado con este mismo problema en mi vida profesional. Usamos marca de tiempo + número aleatorio y nos encontramos con problemas graves cuando nuestras aplicaciones se ampliaron (más clientes, más servidores, más solicitudes). Por supuesto, usamos (estúpidamente) solo 4 dígitos y luego cambiamos a 6, pero te sorprendería la frecuencia con la que aún ocurren errores.
Durante un período de tiempo lo suficientemente largo, está garantizado para obtener errores de clave duplicada. Nuestra aplicación es de misión crítica y, por lo tanto, incluso la más mínima posibilidad de que pudiera fallar debido a un comportamiento intrínsecamente aleatorio era inaceptable. Comenzamos a usar UUID para evitar este problema y administramos cuidadosamente su creación.
Con el uso de UUID, el tamaño de su índice aumentará y un índice más grande dará como resultado un rendimiento más bajo (quizás imperceptible, pero de todos modos más pobre). Sin embargo, MySQL admite un tipo de UUID nativo (¡nunca use varchar como clave principal!), Y puede manejar la indexación, la búsqueda, etc. de manera bastante eficiente, incluso en comparación con bigint. El mayor impacto en el rendimiento de su índice es casi siempre la cantidad de filas indexadas, en lugar del tamaño del elemento que se indexa (a menos que desee indexar en un texto largo o algo ridículo como ese).
Para responder a su pregunta:Bigint (con números aleatorios adjuntos) estará bien si no planea escalar su aplicación/servicio de manera significativa. Si su código puede manejar el cambio sin mucha alteración y su aplicación no explotará si ocurre un error de clave duplicada, hágalo. De lo contrario, muerde la bala y opta por la opción más sustancial.
Siempre puede implementar un cambio mayor más tarde, como cambiar a un backend completamente diferente (al que ahora nos enfrentamos... :P)
