Database Indexing: Nambah 1 Baris Kode, Query 8 Detik Jadi 0,01 Detik

Bayangin Budi Cari Satu Pesanan di Antara 500 Ribu Baris...

Bayangin tabel orders milik Budi sudah berisi 500 ribu baris data setelah dua tahun berjualan. Suatu hari customer service butuh mencari satu pesanan lewat nomor invoice: SELECT * FROM orders WHERE invoice_number = 'INV-88213'.

Query yang harusnya instan itu ternyata butuh 8 detik untuk merespons! CPU database melonjak, dan tim support mengeluh aplikasinya lemot. Padahal hardware server-nya baru dan cukup kencang.

Masalahnya: Database Membaca Satu Per Satu dari Halaman Pertama

Tanpa bantuan apapun, Database akan melakukan Full Table Scan — ia membuka baris pertama, mengecek apakah invoice_number-nya cocok, lalu pindah ke baris kedua, ketiga, dan seterusnya, sampai seluruh 500 ribu baris habis diperiksa satu-satu. Ini persis seperti mencari satu nama di buku telepon setebal 500 ribu halaman dengan cara membalik halamannya satu per satu dari halaman pertama, tanpa tahu bahwa nama-nama itu sebenarnya sudah tersusun alfabetis.

Nah, Di Sinilah 'Index' Masuk!

Index adalah struktur data tambahan (umumnya berbentuk B-Tree, mirip pohon bercabang) yang dibuat Database secara khusus untuk satu kolom, agar kolom itu bisa dicari lewat jalan pintas, layaknya daftar isi di sebuah buku tebal.

CREATE INDEX idx_invoice_number ON orders (invoice_number);

1. Setelah Index dibuat, Database tidak lagi membalik halaman satu-satu. Ia langsung melompat ke "cabang pohon" yang sesuai dengan huruf awal INV-88213, membelah pencarian menjadi dua terus-menerus (mirip permainan tebak angka 1-1000), hingga ketemu dalam hitungan belasan langkah saja, bukan 500 ribu langkah.
2. Query yang tadinya 8 detik pun turun drastis menjadi 0,01 detik.

Tapi Index bukan sihir gratis: setiap kali ada data baru masuk (INSERT), Database juga harus memperbarui struktur pohon Index-nya, sehingga proses tulis jadi sedikit lebih lambat. Karena itu, Index sebaiknya hanya dipasang di kolom yang sering dicari atau dipakai untuk JOIN/ORDER BY (seperti email, slug, invoice_number), bukan di semua kolom asal-asalan.

Intinya: Kalau sebuah query SELECT ... WHERE terasa lambat padahal datanya sudah banyak, langkah pertama yang wajib dicek bukan menambah RAM server, tapi memastikan kolom yang dicari itu sudah punya Index.