私は私の職業生活の中でこの非常に問題に遭遇しました。タイムスタンプ+ランダム番号を使用し、アプリケーションがスケールアップしたときに深刻な問題が発生しました（クライアント、サーバー、リクエストの増加）。確かに、私たちは（ばかげて）4桁しか使用せず、その後6桁に変更しましたが、エラーがまだ発生する頻度に驚かれることでしょう。
十分に長い期間にわたって、あなたは保証されます 重複キーエラーを取得します。私たちのアプリケーションはミッションクリティカルであるため、本質的にランダムな動作が原因で失敗する可能性がわずかでも許容できませんでした。この問題を回避するためにUUIDの使用を開始し、UUIDの作成を慎重に管理しました。
UUIDを使用すると、インデックスサイズが大きくなり、インデックスが大きくなるとパフォーマンスが低下します（おそらく目立たないかもしれませんが、それでもパフォーマンスは低下します）。ただし、MySQLはネイティブUUIDタイプをサポートし（主キーとしてvarcharを使用しないでください!!）、bigintと比較しても、インデックス作成や検索などを非常に効率的に処理できます。インデックスに最大のパフォーマンスの影響を与えるのは、ほとんどの場合、インデックスに登録されているアイテムのサイズではなく、インデックスに登録されている行の数です（ロングテキストなどのばかげたものにインデックスを付けたい場合を除く）。
質問に答えるには：アプリケーション/サービスを大幅に拡張する予定がない場合は、Bigint（ランダムな数字が付加されている）で問題ありません。コードがあまり変更せずに変更を処理でき、重複キーエラーが発生してもアプリケーションが爆発しない場合は、それを使用してください。それ以外の場合は、弾丸を噛んで、より実質的なオプションを選択してください。
まったく異なるバックエンドに切り替えるなど、後でいつでも大きな変更を実装できます（現在直面しているのは...：P）