Skip to Content

My Indexing Strategy for Every SQL Project

Baik, rekan-rekan sekalian. Mari kita bedah strategi indexing SQL yang efektif.

Saya di sini sebagai rekan Anda yang telah melihat banyak proyek gagal atau melambat hanya karena satu hal: strategi indexing yang buruk atau bahkan tidak ada sama sekali.

Tanpa strategi yang jelas, saya jamin Anda akan menghadapi mimpi buruk: redundansi index di mana-mana, index yang tidak pernah terpakai, pemborosan storage yang sia-sia, dan puncaknya, keseluruhan sistem proyek Anda akan menjadi lambat dan berat.

Di sini, saya akan membagikan strategi indexing yang biasa saya ikuti. Tapi ingat, tidak ada satu strategi yang cocok untuk semua skenario. Tim Anda harus brainstorming untuk merumuskan strategi mereka sendiri.

Mari kita mulai.

👑 Aturan Emas: HINDARI OVER-INDEXING

Jika Anda hanya boleh mengambil satu pelajaran dari materi ini, ambil pelajaran ini: Hindari over-indexing.

Ini adalah kesalahan terbesar dan jebakan paling umum yang dilakukan banyak developer. Mereka berpikir, "Semakin banyak index, semakin cepat query kita." Ini salah besar dan justru berujung sebaliknya.

Inilah alasannya:

  1. Memperlambat Operasi Tulis (INSERT, UPDATE, DELETE): Setiap kali Anda menambahkan data baru, mengubah, atau menghapusnya, index Anda harus diperbarui, diurutkan ulang, dan diatur kembali. Semakin banyak index yang Anda miliki, semakin lambat operasi tulis Anda. Database Anda menjadi lebih lambat, bukan lebih cepat.
  2. Membuat Database Bingung: Ini alasan yang sangat penting. Anda membuat database bingung saat membuat execution plan. Database SQL harus membuat rencana eksekusi terbaik untuk query Anda. Jika Anda memiliki terlalu banyak index, proses ini menjadi rumit. Database akan lebih sulit memilih jalur dan index terbaik, dan ini membuka pintu bagi execution plan yang buruk.
  3. Memperlambat Query Itu Sendiri: Kebingungan di Poin 2 memakan waktu. Database harus membuat execution plan sebelum mengeksekusi query. Jika proses pembuatannya rumit, total waktu eksekusi query Anda justru bertambah lambat.

Ingat, over-indexing adalah pedang bermata dua. Di sinilah Anda harus memiliki mindset "Less is More".

Memiliki beberapa index yang efektif jauh lebih baik daripada memiliki banyak index yang tidak jelas. Tulis ini besar-besar di panduan pengembangan tim Anda: HINDARI OVER-INDEXING.

👉 Apa yang bisa kamu lakukan sekarang: Buka dokumen panduan developer tim Anda dan tulis di bagian paling atas bagian SQL: "ATURAN #1: HINDARI OVER-INDEXING. Setiap index baru harus memiliki justifikasi yang jelas."

🧠 Sudut Pandang yang Jarang Dilihat: Indeks Bukan Tombol "Percepat", Tapi "Petunjuk"

Banyak orang melihat index sebagai tombol "percepat" ajaib. Ini keliru.

Lihatlah index sebagai petunjuk yang Anda berikan kepada Query Optimizer (mesin pembuat keputusan di database).

  • Skenario Baik (Indexing Tepat): Anda memberi optimizer satu peta yang sangat jelas dan akurat. Optimizer melihat peta itu dan langsung tahu jalan tercepat.
  • Skenario Buruk (Over-Indexing): Anda memberi optimizer 50 peta yang berbeda, beberapa tumpang tindih, beberapa sudah usang. Optimizer sekarang harus menghabiskan sebagian besar waktunya hanya untuk membandingkan 50 peta itu sebelum akhirnya bisa mulai "berjalan".

Over-indexing tidak hanya memperlambat write, tapi juga membuang-buang waktu optimizer. Fokus Anda seharusnya adalah memberikan petunjuk yang paling jelas dan paling sedikit yang diperlukan, bukan petunjuk sebanyak mungkin.

👉 Apa yang bisa kamu lakukan sekarang: Ubah mindset Anda. Saat membuat index, jangan bertanya, "Apakah ini akan membuat query lebih cepat?" Tanyakan, "Apakah optimizer kekurangan petunjuk ini untuk menemukan data secara efisien?"

🚀 Strategi Indexing 4 Fase

Strategi saya terbagi menjadi empat fase, bergerak dari yang paling umum ke yang paling spesifik.

Fase 1: Strategi Indexing Awal (Tentukan Tujuan)

Saat Anda memulai proyek baru, definisikan tujuannya dengan jelas. Untuk melakukan itu, Anda harus memahami tipe sistem Anda.

Ada dua tipe utama:

  1. OLAP (Online Analytical Processing):
    • Contoh: Data Warehouse.
    • Proses: Data diekstrak dari banyak sumber (ETL), disiapkan, dan disimpan di satu storage besar.
    • Penggunaan: Laporan dan dashboard untuk analitik.
    • Sifat: Sangat berat di operasi BACA (Read). Query yang berjalan sangat besar, kompleks, dan butuh agregasi data. Proses write (ETL) biasanya hanya terjadi sekali sehari (misalnya, di malam hari).
    • Tujuan Utama: Mengoptimalkan performa BACA (Read).
  2. OLTP (Online Transactional Processing):
    • Contoh: E-commerce, Perbankan, Keuangan.
    • Proses: Aplikasi front-end yang digunakan pengguna secara real-time.
    • Penggunaan: Transaksi kecil tapi masif.
    • Sifat: Campuran berat antara BACA (Read) dan TULIS (Write).
    • Tujuan Utama: Seringkali, titik sakitnya (pain point) adalah mengoptimalkan performa TULIS (Write) agar transaksi pengguna tidak terhambat.

Setelah tahu tujuannya, ini strategi awalnya:

  • Jika OLAP (Fokus Read):
    • Gunakan Columnstore Index pada tabel FAKTA (Fact Tables) Anda yang sangat besar. Ini adalah game-changer untuk query agregasi yang berat. Jadikan ini sebagai strategi utama untuk semua fact table Anda.
  • Jika OLTP (Fokus Write):
    • Buat Clustered Index untuk setiap Primary Key (PK) di tabel Anda. Ini akan mempercepat pencarian, pengurutan, dan join tabel.
    • HATI-HATI! Anda harus jauh lebih sensitif dan berhati-hati dalam menambahkan index baru (Non-Clustered) dibandingkan sistem OLAP. Setiap index tambahan adalah "pajak" untuk performa write Anda.

👉 Apa yang bisa kamu lakukan sekarang: Tentukan dengan jelas: Apakah proyek Anda OLAP atau OLTP? Tuliskan tujuan utama Anda: "Optimasi Read" atau "Optimasi Write". Ini akan menjadi kompas untuk semua keputusan indexing Anda ke depan.

Fase 2: Indexing Berbasis Pola Penggunaan (Usage Patterns)

Sekarang kita deep dive ke proyek Anda.

  1. Identifikasi Tabel & Kolom yang Sering Digunakan:
    • Lihat query di kode aplikasi Anda. Tabel mana yang paling sering di-JOIN? Kolom mana yang paling sering muncul di klausa WHERE?
    • Misalnya, Anda melihat kolom OrderDateKey selalu digunakan untuk mem-filter data di 10 query yang berbeda. Ini adalah kandidat kuat untuk index.
  2. Gunakan Bantuan AI (Pro Tip):
    • Saya sering menggunakan AI (seperti ChatGPT). Saya memberikan skrip SQL saya dan meminta laporan statistik penggunaan.
    • Contoh Prompt: "Analisis query SQL berikut. Buat laporan statistik penggunaan tabel dan kolom. Untuk setiap tabel, berikan total berapa kali digunakan. Untuk setiap kolom, tunjukkan berapa kali muncul dan penggunaan utamanya (misal: filtering, joining, grouping)."
    • Ini memberi Anda gambaran cepat tentang tabel dan kolom terpenting Anda.
  3. Pilih Tipe Index yang Tepat:
    • Clustered: Untuk Primary Key.
    • Non-Clustered: Untuk kolom non-PK yang sering dipakai untuk filtering (WHERE) atau joining (JOIN).
    • Columnstore: Untuk tabel fact OLAP yang besar.
    • Filtered: Jika Anda hanya menargetkan subset data (misal: WHERE Status = 'Active').
    • Unique: Untuk kolom yang datanya harus unik.
  4. Uji Index Anda: Selalu uji setelah dibuat.

👉 Apa yang bisa kamu lakukan sekarang: Ambil 5 query yang paling sering dieksekusi di aplikasi Anda. Analisis script-nya. Buat daftar tabel dan kolom yang paling sering digunakan untuk WHERE, JOIN, dan GROUP BY. Daftar ini adalah kandidat index prioritas Anda.

Fase 3: Indexing Berbasis Skenario (Atasi Pain Point)

Fase ini berfokus pada masalah spesifik.

  1. Identifikasi Query Lambat: Dapatkan laporan dari pengguna atau dari log database Anda. Query mana yang menyebabkan masalah performa?
  2. Analisis Execution Plan: Ini adalah waktu untuk menggali execution plan. Lihat bagaimana SQL mengeksekusi query Anda.
    • Cari "Table Scan" atau "Full Scan". Ini adalah bendera merah. Artinya, database membaca seluruh tabel karena tidak menemukan index yang pas.
    • Cari operasi mahal seperti "Nested Loop Joins" pada tabel besar.
  3. Pilih Index yang Tepat (untuk masalah itu): Berdasarkan temuan di execution plan, buat index yang spesifik untuk mengatasi bottleneck tersebut.
  4. Uji (Sebelum & Sesudah): Jalankan execution plan lagi. Pastikan query Anda sekarang menggunakan index yang baru Anda buat. Bandingkan biayanya. Jika tidak ada perubahan, ada yang salah. Mungkin Anda perlu index yang berbeda.

Ingat, indexing bukan satu-satunya cara optimasi query, tapi seringkali yang paling berdampak.

👉 Apa yang bisa kamu lakukan sekarang: Minta 1 query yang dilaporkan paling lambat oleh pengguna. Buka execution plan-nya. Cari operasi dengan cost tertinggi (misalnya, 'Table Scan' 90%). Buat index pada kolom yang digunakan di WHERE atau JOIN pada operasi tersebut. Jalankan ulang execution plan dan lihat cost-nya turun drastis.

Fase 4: Monitoring dan Pemeliharaan (Tugas Tak Berujung)

Pekerjaan Anda tidak berhenti setelah membuat index. Anda harus bertanggung jawab menjaganya.

  1. Monitor Penggunaan Index (Cari yang Tidak Terpakai):
    • Database menyediakan statistik (Dynamic Management Views/DMV) untuk melihat berapa kali sebuah index digunakan.
    • Jika Anda menemukan index yang telah Anda buat tapi tidak pernah digunakan, hapus index itu! Itu hanya memperlambat operasi write Anda tanpa memberi manfaat apa pun.
  2. Monitor Index yang Hilang (Missing Indexes):
    • Execution plan seringkali memberikan rekomendasi "missing index". Gunakan ini sebagai petunjuk, tapi jangan ikuti secara membabi buta (ingat Aturan Emas: Hindari Over-indexing).
  3. Monitor Index Duplikat:
    • Ini sering terjadi di tim besar. Dua developer mengoptimasi query yang mirip dan akhirnya membuat dua index yang hampir identik pada kolom yang sama. Ini adalah pemborosan. Cari dan konsolidasikan mereka.
  4. Perbarui Statistik (PENTING!):
    • Execution plan dibuat berdasarkan statistik data. Jika statistiknya kedaluwarsa (data sudah banyak berubah), database akan membuat keputusan yang salah.
    • Rekomendasi saya: Buat job otomatis yang memperbarui semua statistik database Anda setiap akhir pekan.
  5. Monitor Fragmentasi:
    • Seiring waktu, saat data diubah, index Anda bisa "berantakan" (terfragmentasi).
    • Aturan praktis:
      • Fragmentasi 0-10%: Abaikan.
      • Fragmentasi 10-30%: Lakukan REORGANIZE.
      • Fragmentasi > 30%: Lakukan REBUILD (ini lebih intensif).
    • Pro Tip: Buat dashboard otomatis (di Power BI atau Tableau) yang mengambil metadata ini untuk memonitor kesehatan database Anda.

👉 Apa yang bisa kamu lakukan sekarang: Jadwalkan 30 menit di kalender Anda minggu depan. Gunakan script DMV untuk menemukan: 1) 5 index teratas yang paling tidak terpakai, dan 2) 5 index teratas dengan fragmentasi tertinggi.

✅ Checklist: Tindak Lanjut Praktis Anda

Ini adalah siklus yang terus berulang. Gunakan ini sebagai checklist Anda:

  1. [ ] Definisikan Tujuan: Apakah proyek saya OLAP (fokus Read) atau OLTP (fokus Write)?
  2. [ ] Terapkan Aturan Emas: Apakah ada index yang saya tambahkan "untuk jaga-jaga"? Hapus.
  3. [ ] Analisis Pola: Apakah saya sudah mengidentifikasi 5 query teratas dan kolom WHERE/JOIN yang mereka gunakan?
  4. [ ] Atasi Pain Point: Apakah saya sudah memeriksa execution plan dari query terlambat yang dilaporkan pengguna?
  5. [ ] Jadwalkan Pemeliharaan: Apakah saya sudah punya rencana untuk:
    • Menghapus index yang tidak terpakai?
    • Memperbarui statistik (misal, setiap akhir pekan)?
    • Memeriksa fragmentasi (misal, setiap bulan)?

Terus ulangi siklus ini. Selalu pertanyakan apakah tujuan Anda masih relevan, terus cari query lambat, dan selalu pantau kesehatan index Anda.

Semoga berhasil.


📚 Glosarium Strategi Indexing: Dari Awam Menjadi Ahli

1. Execution Plan (Rencana Eksekusi)

  • Definisi: Serangkaian langkah yang diputuskan oleh database untuk mengambil data yang Anda minta dalam sebuah query. Ini adalah "resep" internal database.
  • Analogi (Google Maps): Anggap query Anda adalah "Saya ingin pergi dari Rumah ke Kantor." Execution Plan adalah rute yang diberikan oleh Google Maps. Apakah akan lewat tol (menggunakan index A), atau lewat jalan tikus (menggunakan index B), atau memutar lewat jalan raya utama (melakukan Table Scan)? Database menghitung "rute tercepat" berdasarkan data yang ia miliki (statistik).
  • Mengapa Ini Penting: Query yang lambat hampir selalu disebabkan oleh Execution Plan yang buruk (Google Maps memilih rute yang macet). Tugas kita adalah memberi petunjuk (indeks) agar Google Maps memilih rute terbaik.

2. Over-indexing

  • Definisi: Kondisi di mana sebuah tabel memiliki terlalu banyak index.
  • Analogi (Buku dengan 10 Daftar Isi): Bayangkan Anda memiliki buku dengan 500 halaman. Anda membuat 10 daftar isi yang berbeda: satu diurutkan berdasarkan Bab, satu berdasarkan abjad topik, satu berdasarkan nama tokoh, satu berdasarkan lokasi, dst.
    • Kelebihan: Mencari info jadi sangat cepat.
    • Kekurangan: Setiap kali Anda merevisi satu paragraf saja di buku itu, Anda harus repot-repot memperbarui semua 10 daftar isi agar tetap akurat. Menulis (Write) buku itu menjadi sangat lambat dan menyakitkan.
  • Mengapa Ini Penting: Inilah jebakan terbesar. Kita pikir kita mempercepat read, tapi kita "membunuh" performa write (INSERT, UPDATE, DELETE).

3. OLTP (Online Transactional Processing)

  • Definisi: Tipe sistem database yang dirancang untuk menangani banyak transaksi kecil dan cepat secara real-time.
  • Studi Kasus (Mesin Kasir Supermarket): Pikirkan mesin kasir. Setiap detik, terjadi puluhan transaksi: "Cek harga barang" (Read), "Kurangi stok barang X" (Write), "Simpan data penjualan baru" (Write). Sistem ini harus sangat cepat merespons operasi write dan read yang kecil-kecil tapi terus menerus.
  • Mengapa Ini Penting: Sistem OLTP (seperti e-commerce, perbankan) sangat sensitif terhadap over-indexing karena fokusnya adalah kecepatan write yang tinggi.

4. OLAP (Online Analytical Processing)

  • Definisi: Tipe sistem database yang dirancang untuk analisis data yang besar dan kompleks, biasanya untuk laporan dan business intelligence.
  • Studi Kasus (Dashboard Direktur): Pikirkan dashboard seorang direktur yang menampilkan "Grafik total penjualan per provinsi selama 5 tahun terakhir." Untuk membuat satu grafik itu, database harus membaca dan menghitung (agregasi) jutaan atau miliaran baris data. Operasi write (memasukkan data baru) mungkin hanya terjadi sekali sehari di tengah malam (proses ETL).
  • Mengapa Ini Penting: Sistem OLAP tidak terlalu peduli pada kecepatan write, tapi sangat butuh kecepatan read yang luar biasa. Indexing di sini boleh lebih "agresif".

5. Clustered Index (Indeks Terkluster)

  • Definisi: Index khusus yang menentukan urutan fisik penyimpanan data di dalam tabel. Hanya boleh ada satu Clustered Index per tabel.
  • Analogi (Kamus Cetak): Sebuah kamus adalah Clustered Index. Data (kata-kata) di dalamnya secara fisik sudah diurutkan berdasarkan abjad (A-Z). Anda tidak perlu daftar isi terpisah, karena datanya sendiri sudah terurut.
  • Mengapa Ini Penting: Ini adalah cara tercepat untuk mencari data jika Anda mencari berdasarkan kolom tersebut (biasanya Primary Key), karena datanya sudah tersusun rapi.

6. Non-Clustered Index (Indeks Non-Kluster)

  • Definisi: Sebuah struktur terpisah (seperti daftar isi) yang menunjuk ke lokasi data fisik. Anda boleh punya banyak Non-Clustered Index.
  • Analogi (Indeks Belakang Buku Teks): Ini adalah daftar "Indeks Topik" di halaman belakang buku. Daftar ini diurutkan berdasarkan topik (misal: "Fragmentasi", "OLAP"), dan setiap topik menunjuk ke nomor halaman di mana data aslinya berada. Halaman-halaman buku itu sendiri (data fisiknya) diurutkan berdasarkan Bab, bukan berdasarkan topik di indeks belakang.
  • Mengapa Ini Penting: Ini digunakan untuk mempercepat pencarian pada kolom-kolom yang sering Anda filter (klausa WHERE) atau join, yang bukan Primary Key.

7. Columnstore Index

  • Definisi: Tipe index spesial (biasanya untuk OLAP) yang menyimpan data berdasarkan kolom, bukan baris.
  • Analogi (Menyimpan Excel):
    • Penyimpanan Normal (Row-store): Menyimpan data per baris: [Faisal, Purworejo, 30], lalu [Budi, Jakarta, 25], lalu [Citra, Bandung, 28].
    • Penyimpanan Columnstore: Menyimpan data per kolom: [Faisal, Budi, Citra], lalu [Purworejo, Jakarta, Bandung], lalu [30, 25, 28].
  • Studi Kasus: Jika Anda menjalankan query "Hitung rata-rata umur semua pelanggan" (OLAP), Columnstore hanya perlu membaca blok data "Umur" [30, 25, 28] dan mengabaikan blok "Nama" dan "Alamat". Ini jauh lebih efisien.
  • Mengapa Ini Penting: Ini adalah senjata rahasia untuk mempercepat query agregasi (SUM, COUNT, AVG) di data warehouse.

8. Table Scan (atau Full Scan)

  • Definisi: Operasi di mana database terpaksa membaca setiap baris dalam tabel dari awal sampai akhir, karena tidak menemukan index yang bisa membantunya.
  • Analogi (Mencari Kata di Novel Tanpa Indeks): Anda ingin mencari kata "Naga" di dalam novel setebal 800 halaman yang tidak punya daftar isi atau indeks. Satu-satunya cara adalah Anda harus membaca setiap halaman, dari halaman 1 sampai 800. Ini adalah operasi yang paling lambat dan paling ingin kita hindari.
  • Mengapa Ini Penting: Jika Anda melihat "Table Scan" di Execution Plan pada tabel yang besar, itu adalah bendera merah besar bahwa indexing Anda bermasalah.

9. Statistics (Statistik Database)

  • Definisi: Metadata (data tentang data) yang melacak distribusi data di dalam kolom.
  • Analogi (Info Lalu Lintas Google Maps): Statistics adalah data "info lalu lintas" yang dipakai Google Maps (Execution Plan). Statistik memberi tahu optimizer: "Jalan A (kolom Status) 90% isinya 'Aktif' dan 10% 'Non-Aktif', sedangkan Jalan B (kolom ID) isinya unik semua." Berbekal info ini, optimizer bisa membuat keputusan cerdas.
  • Mengapa Ini Penting: Jika statistik Anda kedaluwarsa (info lalu lintasnya dari seminggu lalu), optimizer akan membuat Execution Plan yang buruk karena didasarkan pada asumsi yang salah. Inilah mengapa "Update Statistics" sangat penting.

10. Fragmentation (Fragmentasi)

  • Definisi: Kondisi di mana urutan data di dalam index menjadi tidak teratur atau "berantakan" seiring waktu karena banyak operasi INSERT, UPDATE, dan DELETE.
  • Analogi (Rak Buku yang Berantakan): Awalnya, rak buku Anda (data) tersusun rapi per abjad. Seiring waktu, Anda mengambil buku (DELETE), menyisipkan buku baru di celah kosong (INSERT), atau memindahkan buku (UPDATE). Lama-kelamaan, urutan buku di rak menjadi acak-acakan dan banyak ruang kosong terselip. Saat Anda mencari buku, Anda harus melompat-lompat antar rak.
  • Mengapa Ini Penting: Fragmentasi memperlambat performa read. Ini bisa diperbaiki dengan:
    • Reorganize: Merapikan buku di rak seadanya (cepat, tidak mengganggu).
    • Rebuild: Mengosongkan seluruh rak, lalu menata ulang semua buku dari awal (lambat, tapi hasil lebih rapi).

👨‍🏫 Cara Mengajarkan Materi Ini ke Orang Lain (Agar Anda Lebih Paham)

Cara terbaik untuk menguasai sesuatu adalah dengan mengajarkannya. Berikut adalah script sederhana yang bisa Anda gunakan untuk menjelaskan ini kepada rekan setim Anda:

"Halo rekan-rekan. Hari ini kita akan membahas sesuatu yang krusial untuk performa aplikasi kita: Strategi Indexing SQL.

1. Mulai dengan 'Mengapa' (Analogi Restoran)

Bayangkan database kita adalah perpustakaan besar atau dapur restoran yang sibuk. Tanpa index, query kita seperti koki yang harus mencari satu bahan spesifik di gudang raksasa yang tidak terorganisir. Dia harus mengecek setiap kotak satu per satu. Ini lambat dan buang-buang waktu. Index adalah label besar di setiap rak yang memberi tahu koki di mana letak 'Garam', 'Merica', dan 'Tepung'.

2. Aturan Emas-nya (Analogi Buku 10 Daftar Isi)

Tapi, ada jebakan. Kita tidak bisa memberi label berlebihan. Ini namanya over-indexing. Bayangkan sebuah buku yang punya 10 daftar isi berbeda. Memang cepat mencari, tapi setiap kali kita revisi satu paragraf, kita harus update ke-10 daftar isi itu! Ini membuat proses menulis (INSERT, UPDATE, DELETE) jadi sangat lambat. Kuncinya: Less is more.

3. Pahami Sistem Kita (Analogi Kasir vs. Dashboard)

Kita harus tahu sistem apa yang kita bangun:

  • Apakah kita OLTP? Seperti mesin kasir e-commerce. Butuh banyak transaksi write dan read kecil yang cepat. Kita harus sangat hati-hati menambah index agar tidak memperlambat transaksi.
  • Atau kita OLAP? Seperti dashboard analitik direktur. Butuh query read yang super berat untuk menghitung jutaan data. Di sini kita bisa lebih agresif memakai index seperti Columnstore.

4. Kenali Senjata Kita (Analogi Kamus vs. Daftar Isi Buku)

Dua index utama kita adalah:

  • Clustered Index (Kamus): Ini adalah data fisiknya yang sudah urut. Cuma boleh ada satu. Ini adalah Primary Key kita.
  • Non-Clustered Index (Daftar Isi): Ini adalah petunjuk terpisah yang menunjuk ke data. Kita pakai ini untuk kolom yang sering kita WHERE atau JOIN.

5. Kenali Musuh Kita (Analogi Novel Tanpa Indeks)

Musuh terbesar kita adalah 'Table Scan'. Ini adalah saat database terpaksa membaca seluruh tabel dari awal sampai akhir, seperti membaca novel 800 halaman untuk mencari satu kata. Jika kita melihat ini di execution plan, index kita gagal.

6. Jangan Lupa Dirawat (Analogi Rak Buku & Info Lalu Lintas)

Index itu tidak 'atur sekali dan lupakan'.

  • Statistik: Database butuh "info lalu lintas" terbaru untuk memilih rute terbaik. Kita harus rutin Update Statistics.
  • Fragmentasi: Seiring waktu, rak buku kita (data) bisa berantakan. Kita harus rutin Reorganize atau Rebuild index kita agar tetap rapi.

Kesimpulan:

Strategi kita adalah 4 Fase:

  1. Awal: Tentukan kita OLTP atau OLAP.
  2. Pola: Cari query yang paling sering dipakai.
  3. Skenario: Cari query paling lambat dan perbaiki execution plan-nya.
  4. Pemeliharaan: Rutin cek index yang tidak terpakai, duplikat, dan terfragmentasi.

Mari kita berkomitmen untuk ini, agar sistem kita tetap cepat dan efisien."

SQL Execution Plans EXPLAINED