Cara Mengambil Baris Acak di SQL

Ambil baris acak di SQL paling gampang pakai ORDER BY RANDOM() lalu LIMIT.

Satu baris query, kelar. Tapi begitu tabelmu gede, cara ini bikin query nungguin lama.

Baris acak kepakai buat banyak hal. Ngambil sampel data buat dicek, milih pemenang undian, atau nyiapin data latihan buat model. Tiap kasus punya cara paling pas.

Di sini kamu bakal tahu cara ambil baris acak per dialek SQL, plus trik biar tetap cepat di tabel besar.

Gimana cara ambil satu baris acak di SQL?

Cara ambil baris acak di SQL adalah mengurutkan tabel pakai fungsi acak lalu batasi hasilnya. Di PostgreSQL pakai ORDER BY RANDOM() LIMIT 1. Tiap baris dikasih nilai acak, diurutin, lalu diambil yang teratas. Cara ini jalan di hampir semua database dengan sedikit beda nama fungsi.

-- PostgreSQL / SQLite
SELECT *
FROM pelanggan
ORDER BY RANDOM()
LIMIT 1;

Ganti LIMIT 1 jadi LIMIT 10 kalau kamu mau 10 baris acak. Logikanya sama.

Gimana ambil baris acak di tiap dialek SQL?

Nama fungsi acaknya beda-beda per database. Intinya sama: kasih tiap baris nilai acak, urutin, batasi. Yang beda cuma fungsi dan sintaks LIMIT. Tabel di bawah nunjukin bentuk yang paling umum dipakai.

-- MySQL
SELECT * FROM pelanggan ORDER BY RAND() LIMIT 5;

-- SQL Server
SELECT TOP 5 * FROM pelanggan ORDER BY NEWID();

Kalau kamu masih baru sama LIMIT dan ORDER BY, cek dulu fungsi ORDER BY biar paham urutan eksekusinya.

Kenapa ORDER BY RANDOM() lambat di tabel besar?

ORDER BY RANDOM() lambat karena database harus kasih nilai acak ke semua baris dulu, baru ngurutin semuanya, baru ambil yang teratas. Buat tabel 10 juta baris, itu artinya 10 juta nilai acak dan pengurutan penuh, cuma buat ambil 5 baris. Kerjanya jauh lebih besar dari hasilnya.

Buat tabel kecil sampai puluhan ribu baris, ini gak masalah. Masalah baru kerasa pas tabelnya ratusan ribu ke atas. Di situ kamu perlu cara lain.

Cara ambil baris acak yang cepat di tabel besar

Buat tabel besar, jangan urutin semua baris. Saring dulu pakai nilai acak per baris, jadi cuma sebagian kecil yang lolos. Ini motong kerjaan pengurutan drastis.

-- Ambil kira-kira 1% baris secara acak, lalu batasi
SELECT *
FROM transaksi
WHERE RANDOM() < 0.01
LIMIT 100;

Cara ini gak ngurutin seluruh tabel. Tiap baris dicek satu kali, lolos kalau nilai acaknya di bawah ambang. Jauh lebih ringan.

Alternatif lain, banyak database punya TABLESAMPLE yang dirancang khusus buat sampling cepat di level penyimpanan.

-- PostgreSQL: sampel sekitar 1% dari tabel
SELECT *
FROM transaksi
TABLESAMPLE SYSTEM (1);

TABLESAMPLE paling cepat, tapi hasilnya kurang benar-benar acak karena ngambil per blok data. Buat statistik ketat, RANDOM() lebih aman. Buat sekadar ngintip data, TABLESAMPLE menang di kecepatan. Detailnya ada di dokumentasi resmi PostgreSQL.

Cara ambil baris acak yang bisa diulang (reproducible)

Kadang kamu butuh sampel acak yang sama tiap kali query dijalanin, misal biar tim lain dapat baris yang sama. Buat itu, kasih seed ke fungsi acaknya. Seed bikin urutan acaknya tetap, jadi hasilnya konsisten.

-- PostgreSQL: set seed dulu, baru query
SELECT setseed(0.42);
SELECT * FROM pelanggan ORDER BY RANDOM() LIMIT 10;

Tanpa seed, tiap jalan dapat baris beda. Dengan seed sama, hasilnya bisa diulang. Ini penting buat analisa yang harus bisa dicek ulang orang lain.

Cara ambil baris acak per grup

Sering kamu gak mau acak dari seluruh tabel, tapi acak per kategori. Misal 1 pelanggan acak dari tiap kota. Buat ini pakai window function ROW_NUMBER() dengan urutan acak di dalam tiap grup.

-- Satu pelanggan acak per kota
WITH acak AS (
  SELECT *,
         ROW_NUMBER() OVER (PARTITION BY kota ORDER BY RANDOM()) AS rn
  FROM pelanggan
)
SELECT * FROM acak WHERE rn = 1;

Baris diacak di dalam tiap kota, dikasih nomor, lalu diambil nomor 1 per kota. Kalau kamu belum akrab sama window function, mulai dari fungsi ROW_NUMBER.

Contoh kasus: sampel QA di toko_berkah

Di dataset ngulikdata, tabel transaksi toko_berkah punya 1,2 juta baris. Tim QA mau ngecek 200 transaksi acak buat verifikasi harga.

Pakai ORDER BY RANDOM() LIMIT 200, query jalan sekitar 4,8 detik di mesin latihan. Diganti jadi WHERE RANDOM() < 0.001 LIMIT 200, turun ke sekitar 0,3 detik. Beda 16 kali lebih cepat buat hasil yang sama gunanya.

Pelajarannya: buat tabel kecil, pakai cara yang paling gampang dibaca. Buat tabel besar, saring dulu sebelum ngurutin.

Kesalahan umum

Pertama, pakai ORDER BY RANDOM() di tabel jutaan baris lalu heran query-nya lama. Saring dulu pakai ambang acak.

Kedua, ngira LIMIT tanpa ORDER BY ngasih baris acak. Nggak. Tanpa ORDER BY, urutannya gak dijamin dan sering ngasih baris yang itu-itu lagi.

Ketiga, lupa kalau TABLESAMPLE gak benar-benar acak per baris. Buat undian atau statistik yang butuh keadilan ketat, pakai RANDOM().

FAQ

Apa bedanya RAND() dan RANDOM() di SQL?

Bedanya cuma di nama, tergantung database. MySQL, MariaDB, dan BigQuery pakai RAND(), sementara PostgreSQL dan SQLite pakai RANDOM(). Fungsinya sama: ngasih angka acak yang kepakai buat ngurutin baris secara acak. SQL Server beda lagi, buat ngacak baris orang biasanya pakai NEWID() karena RAND() di SQL Server ngasih satu nilai per query, bukan per baris.

Gimana ambil persentase baris acak, bukan jumlah tetap?

Pakai filter nilai acak per baris. Misal WHERE RANDOM() < 0.05 ngambil kira-kira 5% baris secara acak, karena tiap baris punya peluang 5% lolos. Jumlah pastinya bakal beda-beda tiap jalan, tapi rata-ratanya sekitar target. Kalau kamu butuh persentase yang lebih presisi dan cepat, banyak database punya TABLESAMPLE yang bisa langsung minta sekian persen dari tabel.

Kenapa hasil baris acak saya selalu sama?

Biasanya karena kamu gak pakai ORDER BY fungsi acak, atau seed-nya kepasang. Kalau cuma pakai LIMIT tanpa ORDER BY, database bebas ngasih urutan apa pun, dan sering itu urutan penyimpanan yang tetap. Pastiin ada ORDER BY RANDOM() atau setara. Kalau kamu sengaja set seed pakai setseed(), hasilnya emang dibikin konsisten, jadi lepas seed-nya kalau mau benar-benar acak.

Apa aman pakai ORDER BY RANDOM() di production?

Aman buat tabel kecil sampai sedang, tapi hati-hati di tabel besar karena bisa berat dan ganggu query lain. Buat tabel jutaan baris, ganti ke filter ambang acak atau TABLESAMPLE yang jauh lebih ringan. Selalu tes dulu di data yang mirip ukuran production, dan lihat waktu jalannya. Query yang cepet di tabel latihan seribu baris bisa jadi lambat banget di tabel produksi jutaan baris.

Penutup

Ambil baris acak di SQL punya dua level. Buat tabel kecil, ORDER BY RANDOM() LIMIT n udah cukup dan paling gampang dibaca.

Buat tabel besar, saring dulu pakai ambang acak atau TABLESAMPLE biar query gak ngurutin seluruh tabel. Butuh hasil yang bisa diulang, pasang seed.

Mau latihan langsung nulis query kayak gini? Coba di NgulikSQL, atau lanjut baca fungsi ROW_NUMBER buat sampling per grup yang lebih rapi.