Pernah nggak sih kepikiran, kenapa setiap data di database harus punya “kunci utama” alias primary key? Nah, primary key ini ibarat KTP buat setiap baris data unik dan nggak boleh sama. Selama ini banyak developer pakai auto increment, karena simpel: tinggal nambah angka 1, 2, 3, dan seterusnya. Tapi ada juga cara lain yang lebih “acak” dan keren, yaitu UUID (Universally Unique Identifier).
Di jurnal yang saya tulis, saya coba bandingin kecepatan baca-tulis data di MySQL kalau pakai auto increment vs UUID. Hasilnya? Menarik banget, karena ternyata masing-masing punya kelebihan dan kekurangan. Yuk, saya ceritain hasil eksperimen ini cekidot.
Latar Belakang
Di era sekarang, hampir semua aktivitas kita nyambung sama data. Dari update status di medsos, pesan makanan online, sampai cek saldo e-wallet — semuanya menghasilkan data dalam jumlah yang gila-gilaan. Dunia teknologi nyebut tren ini sebagai big data, karena data yang dikumpulkan bukan cuma banyak, tapi juga terus nambah setiap detik.
Nah, di balik layar semua aplikasi yang kita pakai, ada “dapur” penting bernama database. Database ini tugasnya nyimpen dan ngatur data biar bisa diakses kapan aja. Masalahnya, semakin besar data yang masuk, semakin penting juga bagaimana cara database tersebut mengatur identitas unik tiap baris data.
Di sinilah peran primary key. Anggap aja primary key itu kayak nomor antrean atau nomor KTP buat data: harus unik, gampang diakses, dan nggak boleh bentrok sama data lain. Selama ini developer biasanya pakai dua metode populer:
Auto Increment → nomor urut otomatis, gampang dipahami, misalnya ID 1, 2, 3, dan seterusnya.
UUID (Universally Unique Identifier) → kode acak berupa kombinasi huruf dan angka yang super panjang, jadi susah ditebak dan nggak terbatas jumlahnya.
Masalahnya, pilihan primary key ini bukan cuma soal gaya, tapi juga ngaruh ke performa database. Bayangin kalau sebuah aplikasi harus nyimpen jutaan bahkan miliaran data, apakah auto increment masih cukup? Atau UUID lebih cocok buat skala besar?
Alur Eksperimen
Jadi, untuk ngetes mana yang lebih oke antara auto increment sama UUID di MySQL, saya bikin eksperimen kecil-kecilan. Ibaratnya, saya “adu balap” dua jenis primary key ini dalam hal nulis data (insert) dan baca data (select).
1. Setup Dulu, Bro!
Sebelum mulai balapan, tentu harus siapin “lintasan” dulu. Saya pakai laptop dengan spesifikasi standar:
– Prosesor Intel Core i5
– RAM 8 GB
– SSD 256 GB
– Sistem Operasi Windows 10
– MySQL versi 5.7
– PHP versi 7
Jadi, semua pengujian dilakukan di environment yang sama biar fair play.
2. Siapkan Dua Skrip Jagoan
Saya bikin dua skrip PHP:
auto.php → buat insert data pakai auto increment.
uuid.php → buat insert data pakai UUID (yang digenerate random pakai function PHP).
Keduanya dibuat dengan logika perulangan (for loop) biar bisa masukin data dalam jumlah besar.
3. Balapan Insert Data
Saya coba masukkan data dengan dua skenario:
– 10.000 baris data
– 50.000 baris data
Tujuannya biar kelihatan, apakah performa beda tipis atau ada gap besar kalau jumlah datanya makin banyak.
4. Uji Kecepatan Baca Data
Setelah data masuk, langkah berikutnya adalah ngetes kecepatan MySQL membaca data yang sudah ada. Sama kayak di insert, saya pakai dua skenario: baca 10.000 baris dan 50.000 baris.
5. Pantau Resource
Biar lebih objektif, saya nggak cuma lihat waktunya doang, tapi juga mantau pemakaian CPU, RAM, dan storage lewat Task Manager. Jadi hasilnya bisa dibandingin dari banyak sisi, bukan sekadar “cepat atau lambat”.
Singkatnya, eksperimennya kayak lomba balap dua motor: satu motor pakai nomor plat berurutan (auto increment), satu lagi pakai nomor acak super panjang (UUID). Tinggal dilihat siapa yang lebih konsisten, lebih cepat, dan lebih hemat bensin (resource komputer).
Hasil Eksperimen: Siapa yang Lebih Ngebut?
Setelah adu balap antara auto increment dan UUID, akhirnya kelihatan nih siapa yang unggul di lintasan MySQL. Berikut ringkasan hasilnya:
🔹 Insert Data (Tambah Data ke Database)
-
10.000 baris data
Auto Increment lebih cepat (sekitar 19 detik) dibanding UUID (sekitar 101 detik).
Artinya, kalau data yang ditulis masih relatif sedikit, auto increment lebih efisien. -
50.000 baris data
Kejutan terjadi! UUID justru lebih cepat (135 detik) dibanding auto increment (148 detik).
Jadi, kalau jumlah datanya makin banyak, UUID mulai menunjukkan taringnya.
🔹 Read Data (Baca Data dari Database)
Untuk membaca data, baik 10.000 maupun 50.000 baris, hasilnya hampir sama. Kecepatan baca data nggak terlalu terpengaruh apakah pakai auto increment atau UUID. Semuanya bisa dibaca dalam waktu kurang dari 1 detik. ⚡
🔹 Resource Usage (CPU, RAM, Storage)
-
Auto Increment cenderung lebih hemat di awal (data kecil), tapi makin berat kalau datanya membengkak.
-
UUID butuh RAM lebih besar sejak awal, tapi performanya stabil ketika datanya makin besar.
Dari eksperimen ini bisa ditarik kesimpulan sederhana
-
Auto Increment cocok dipakai kalau datanya nggak terlalu banyak, atau untuk aplikasi kecil-menengah yang butuh simplicity.
-
UUID lebih pas buat aplikasi yang berhubungan dengan big data atau sistem skala besar, karena lebih tahan banting dalam jangka panjang (plus lebih aman karena ID-nya susah ditebak).
Kalau diibaratkan lomba lari:
-
Auto Increment itu kayak sprinter, gesit di awal tapi ngos-ngosan kalau jaraknya makin jauh.
-
UUID itu kayak pelari maraton, start agak lambat tapi makin stabil dan kuat kalau jaraknya panjang.
Kesimpulan
Dari eksperimen kecil ini, saya jadi makin yakin bahwa pemilihan primary key di database itu bukan sekadar formalitas, tapi beneran ngaruh ke performa aplikasi.
– Kalau aplikasi kita masih skala kecil atau jumlah datanya belum banyak, auto increment bisa jadi pilihan aman: gampang, cepat, dan nggak ribet.
– Tapi kalau aplikasi kita sudah masuk ke ranah big data, dengan data yang jumlahnya bisa miliaran, UUID mulai terlihat lebih unggul: lebih stabil, lebih fleksibel, dan pastinya lebih aman dari sisi prediksi ID.
Singkatnya:
-
Auto Increment = simpel, gesit di awal.
-
UUID = tahan banting di skala besar.
Pada akhirnya, pilihan balik lagi ke kebutuhan sistem. Nggak ada yang mutlak lebih baik, semua ada plus-minusnya. Tapi dengan tahu hasil perbandingan ini, kita bisa lebih bijak dalam menentukan strategi desain database.
Jadi, lain kali kalau lagi bikin aplikasi dan bingung pilih antara auto increment atau UUID, coba ingat eksperimen ini. Siapa tahu bisa jadi bahan pertimbangan sebelum nentuin “KTP” buat data-data di sistemmu.