Ich bin in meinem Berufsleben auf genau dieses Problem gestoßen. Wir haben Zeitstempel + Zufallszahl verwendet und sind beim Hochskalieren unserer Anwendungen auf ernsthafte Probleme gestoßen (mehr Clients, mehr Server, mehr Anfragen). Zugegeben, wir haben (dummerweise) nur 4 Ziffern verwendet und dann auf 6 geändert, aber Sie wären überrascht, wie oft die Fehler trotzdem auftreten.
Über einen ausreichend langen Zeitraum sind Sie garantiert doppelte Schlüsselfehler zu erhalten. Unsere Anwendung ist geschäftskritisch, und daher war selbst die kleinste Möglichkeit, dass sie aufgrund von inhärent zufälligem Verhalten fehlschlagen könnte, inakzeptabel. Wir haben begonnen, UUIDs zu verwenden, um dieses Problem zu vermeiden, und ihre Erstellung sorgfältig verwaltet.
Durch die Verwendung von UUIDs erhöht sich Ihre Indexgröße, und ein größerer Index führt zu einer schlechteren Leistung (möglicherweise unbemerkt, aber dennoch schlechter). MySQL unterstützt jedoch einen nativen UUID-Typ (verwenden Sie niemals varchar als Primärschlüssel!!) und kann die Indizierung, Suche usw. selbst im Vergleich zu bigint verdammt effizient handhaben. Die größte Leistungseinbuße für Ihren Index ist fast immer die Anzahl der indizierten Zeilen und nicht die Größe des Elements, das indiziert wird (es sei denn, Sie möchten einen Langtext oder etwas Ähnliches indizieren).
Um Ihre Frage zu beantworten:Bigint (mit angehängten Zufallszahlen) ist in Ordnung, wenn Sie nicht vorhaben, Ihre Anwendung / Ihren Dienst erheblich zu skalieren. Wenn Ihr Code die Änderung ohne große Änderungen verarbeiten kann und Ihre Anwendung nicht explodiert, wenn ein doppelter Schlüsselfehler auftritt, machen Sie mit. Andernfalls beißen Sie in den sauren Apfel und wählen Sie die umfangreichere Option.
Sie können später immer noch eine größere Änderung vornehmen, z. B. den Wechsel zu einem völlig anderen Backend (vor dem wir jetzt stehen ... :P)
