W życiu zawodowym zetknąłem się z tym problemem. Użyliśmy znacznika czasu + losowej liczby i napotkaliśmy poważne problemy, gdy nasze aplikacje się skalowały (więcej klientów, więcej serwerów, więcej żądań). To prawda, że (głupio) użyliśmy tylko 4 cyfr, a następnie zmieniliśmy na 6, ale zdziwiłbyś się, jak często błędy nadal się zdarzają.
Przez wystarczająco długi czas masz gwarantowaną aby uzyskać zduplikowane błędy kluczy. Nasza aplikacja ma kluczowe znaczenie dla misji i dlatego nawet najmniejsza szansa, że może się nie powieść z powodu z natury losowego zachowania, była nie do zaakceptowania. Aby uniknąć tego problemu, zaczęliśmy używać identyfikatorów UUID i starannie zarządzaliśmy ich tworzeniem.
Używając identyfikatorów UUID, rozmiar twojego indeksu wzrośnie, a większy indeks spowoduje gorszą wydajność (być może niezauważalną, ale gorszą, niemniej jednak). Jednak MySQL obsługuje natywny typ UUID (nigdy nie używaj varchar jako klucza podstawowego!!) i może obsługiwać indeksowanie, wyszukiwanie itp. dość wydajnie, nawet w porównaniu z bigint. Największym osiągnięciem wydajności w indeksie jest prawie zawsze liczba indeksowanych wierszy, a nie rozmiar indeksowanego elementu (chyba że chcesz indeksować w długim tekście lub czymś tak absurdalnym).
Aby odpowiedzieć na Twoje pytanie:Bigint (z dołączonymi losowymi liczbami) będzie w porządku, jeśli nie planujesz znacząco skalować swojej aplikacji/usługi. Jeśli twój kod może obsłużyć zmianę bez większych zmian, a aplikacja nie wybuchnie, jeśli wystąpi błąd zduplikowanego klucza, idź z tym. W przeciwnym razie ugryź kulkę i wybierz bardziej istotną opcję.
Zawsze możesz później zaimplementować większą zmianę, na przykład przejście na zupełnie inny backend (z czym teraz mamy do czynienia... :P)
