Saya telah mengalami masalah ini dalam kehidupan profesional saya. Kami menggunakan stempel waktu + nomor acak dan mengalami masalah serius saat aplikasi kami ditingkatkan (lebih banyak klien, lebih banyak server, lebih banyak permintaan). Memang, kami (bodohnya) hanya menggunakan 4 digit, lalu mengubahnya menjadi 6, tetapi Anda akan terkejut betapa seringnya kesalahan itu masih terjadi.
Dalam jangka waktu yang cukup lama, Anda dijamin untuk mendapatkan kesalahan kunci duplikat. Aplikasi kami sangat penting untuk misi, dan oleh karena itu, bahkan peluang terkecil yang dapat gagal karena perilaku acak yang inheren tidak dapat diterima. Kami mulai menggunakan UUID untuk menghindari masalah ini, dan mengelola pembuatannya dengan cermat.
Menggunakan UUID, ukuran indeks Anda akan meningkat, dan indeks yang lebih besar akan menghasilkan kinerja yang lebih buruk (mungkin tidak terlalu mencolok, tetapi tetap saja lebih buruk). Namun MySQL mendukung tipe UUID asli (jangan pernah menggunakan varchar sebagai kunci utama!!), dan dapat menangani pengindeksan, pencarian, dll dengan sangat efisien bahkan dibandingkan dengan bigint. Kinerja terbesar yang dicapai indeks Anda hampir selalu merupakan jumlah baris yang diindeks, bukan ukuran item yang diindeks (kecuali jika Anda ingin mengindeks pada teks panjang atau sesuatu yang konyol seperti itu).
Untuk menjawab pertanyaan Anda:Bigint (dengan nomor acak terlampir) akan baik-baik saja jika Anda tidak berencana untuk menskalakan aplikasi/layanan Anda secara signifikan. Jika kode Anda dapat menangani perubahan tanpa banyak perubahan dan aplikasi Anda tidak akan meledak jika terjadi kesalahan kunci duplikat, lakukanlah. Jika tidak, gigit peluru dan pilih opsi yang lebih substansial.
Anda selalu dapat menerapkan perubahan yang lebih besar nanti, seperti beralih ke backend yang sama sekali berbeda (yang sekarang kita hadapi... :P)
