J'ai rencontré ce problème dans ma vie professionnelle. Nous avons utilisé l'horodatage + un nombre aléatoire et avons rencontré de sérieux problèmes lorsque nos applications ont évolué (plus de clients, plus de serveurs, plus de requêtes). Certes, nous n'avons (bêtement) utilisé que 4 chiffres, puis nous avons changé pour 6, mais vous seriez surpris de la fréquence à laquelle les erreurs se produisent encore.
Sur une période suffisamment longue, vous êtes garanti pour obtenir des erreurs de clé en double. Notre application est essentielle à la mission, et par conséquent, même la plus petite chance qu'elle puisse échouer en raison d'un comportement intrinsèquement aléatoire était inacceptable. Nous avons commencé à utiliser les UUID pour éviter ce problème et avons soigneusement géré leur création.
En utilisant les UUID, la taille de votre index augmentera et un index plus grand entraînera de moins bonnes performances (peut-être imperceptibles, mais néanmoins moins bonnes). Cependant, MySQL prend en charge un type UUID natif (n'utilisez jamais varchar comme clé primaire !!) et peut gérer l'indexation, la recherche, etc. de manière très efficace, même par rapport à bigint. Le plus gros impact sur les performances de votre index est presque toujours le nombre de lignes indexées, plutôt que la taille de l'élément indexé (sauf si vous souhaitez indexer sur un texte long ou quelque chose de ridicule comme ça).
Pour répondre à votre question :Bigint (avec des nombres aléatoires attachés) ira bien si vous ne prévoyez pas de faire évoluer votre application/service de manière significative. Si votre code peut gérer le changement sans trop de modifications et que votre application n'explosera pas si une erreur de clé en double se produit, allez-y. Sinon, mordez la balle et optez pour l'option la plus substantielle.
Vous pouvez toujours implémenter un changement plus important plus tard, comme passer à un backend entièrement différent (auquel nous sommes maintenant confrontés... :P)
