Indexing
Indeks (index) itu seperti daftar isi di belakang buku: ia memungkinkan basis data langsung melompat ke baris yang cocok alih-alih memeriksa satu per satu. Tanpa indeks, query menjadi makin lambat seiring bertambahnya data — baik-baik saja pada 100 baris, menyakitkan pada 1.000.000 baris.
Tanpa indeks, basis data memeriksa setiap baris satu per satu; dengan indeks ia langsung melompat ke yang cocok, sama seperti daftar isi buku mengarahkanmu ke halaman yang tepat alih-alih membaca dari sampul ke sampul:
NO INDEX (Seq Scan) WITH INDEX (Index Scan)
read EVERY row, one by one jump straight to matches
┌─────────────────────┐ ┌─────────────┐
│ row 1 ✗ │ │ INDEX │
│ row 2 ✗ │ │ author_id │
│ row 3 ✓ match │ ◀──────┐ │ ──┬── │
│ row 4 ✗ │ │ └─────┼───────┘
│ ... (1,000,000) │ │ ▼
│ row N ✓ match │ └──▶ rows 3, 998 ✓
└─────────────────────┘ a few hops, not a million
Panduan praktisnya:
- Beri indeks pada kolom yang sering kamu pakai untuk filter atau join. (mis.
author_id,email). - Primary key otomatis diberi indeks.
- Jangan beri indeks pada semua kolom — setiap indeks mempercepat pembacaan (reads) tapi memperlambat penulisan (writes) dan memakan ruang.
- Tambahkan indeks ketika kamu melihat query yang lambat, bukan secara preemptif untuk setiap kolom.
Cara jujur untuk mengetahui apakah sebuah indeks membantu adalah dengan bertanya ke basis datanya, bukan menebak. Setiap mesin punya EXPLAIN (di Postgres, EXPLAIN ANALYZE), yang menunjukkan rencana eksekusi (plan) yang akan dipakainya:
EXPLAIN ANALYZE
SELECT * FROM posts WHERE author_id = '...';
Jika output menunjukkan Seq Scan pada tabel besar, basis data sedang membaca setiap baris — tanda bahwa indeks akan membantu. Setelah menambahkannya, ia semestinya beralih ke Index Scan. Ini adalah tugas yang bagus untuk diserahkan ke AI: tempelkan query yang lambat beserta output EXPLAIN, dan tanyakan indeks mana yang perlu ditambahkan serta alasannya. Kamu tetap memegang kendali dengan memahami jawabannya, bukan dengan menghafal teori indeks.