# Indexing Strategis MariaDB untuk Query Kompleks Berjuta Baris

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/indexing-strategis-mariadb-untuk-query-kompleks-berjuta-baris

---

## 1. Intisari Kilat: Fondasi dalam Sekali Lirik

Pernahkah Anda mendapati aplikasi web melambat secara drastis, CPU server database melompat ke angka 100%, dan panel Sentry dipenuhi laporan *Gateway Timeout* dari Nginx? Di ruang kendali infrastruktur, skenario ini biasanya bermuara pada satu tersangka utama: tabel MariaDB yang membengkak hingga puluhan juta baris tanpa strategi *indexing* yang matang. Sebagai arsitek yang sering harus menyelamatkan sistem produksi di tengah malam, saya belajar bahwa mengandalkan intuisi saja tidak cukup; kita membutuhkan presisi bedah yang menggabungkan analisis *execution plan*, strategi komposit, dan pemartisian data.

> [!IMPORTANT]
> Indeks bukan sekadar hiasan untuk mempercepat `SELECT`. Setiap indeks yang Anda buat adalah komitmen ruang disk dan memori RAM yang harus diperbarui secara sinkron setiap kali operasi `INSERT`, `UPDATE`, atau `DELETE` dieksekusi.

Mari kita bedah fondasi pertama yang wajib dikuasai sebelum menyentuh tombol produksi. Ketika sebuah query melambat pada tabel dengan jutaan data, langkah paling haram adalah melakukan *Full Table Scan* ($O(N)$). Tugas kita adalah mengubah kompleksitas tersebut menjadi pencarian terstruktur berbasis *B-Tree* ($O(log N)$).

## 2. Kompas Keputusan: Kapan Memilih Solusi Ini vs Alternatif Lain

Menentukan apakah Anda harus membuat *Single Index*, *Composite Index*, atau melakukan *Table Partitioning* sering kali membingungkan jika tidak memiliki panduan navigasi yang jelas. Bayangkan Anda sedang mengelola tabel log transaksi berukuran 50 GB. Apakah cukup dengan menambah indeks biasa?

- **Jika query Anda hanya menyaring berdasarkan satu kolom dengan kardinalitas tinggi** (misalnya `uuid`), maka **Single Index** sudah lebih dari cukup. Jangan buang sumber daya untuk membuat indeks komposit.
- **Jika query Anda sering memfilter berdasarkan kombinasi kolom secara bersamaan** (misalnya `WHERE status = 'active' AND created_at > '2026-01-01'`), maka **Composite Index** adalah jalan pintas mutlak. Ingat aturan emas: urutan kolom dalam indeks komposit sangat menentukan (gunakan prinsip *Leftmost Prefix*).
- **Jika tabel Anda melampaui 50 juta baris atau ukuran fisik file melampaui RAM server**, penambahan indeks saja tidak akan menolong karena *Buffer Pool* akan mengalami *thrashing*. Saat inilah Anda wajib menerapkan **Partisi Tabel MariaDB** (berbasis *Range* atau *Hash*) untuk memotong ruang pencarian secara fisik.

> [!TIP]
> Sebelum memutuskan melakukan partisi, pastikan Anda telah menguji *Composite Index* dengan urutan kolom yang menempatkan kolom dengan kesamaan nilai terendah di posisi kiri, dan kolom unik di posisi kanan.

## 3. Contekan Konfigurasi & Parameter Paling Sering Dicari

Untuk mendukung performa indeks pada skala masif, konfigurasi *engine* MariaDB di `/etc/mysql/mariadb.conf.d/50-server.cnf` memegang peran vital. Berikut adalah parameter esensial yang wajib Anda sesuaikan berdasarkan kapasitas RAM server:

```ini
[mysqld]
# Alokasikan 70-80% RAM server khusus untuk InnoDB Buffer Pool jika server dedicated DB
innodb_buffer_pool_size = 12G

# Pecah buffer pool menjadi beberapa instance untuk mengurangicontention pada sistem multi-core
innodb_buffer_pool_instances = 8

# Ukuran log file untuk transaksi besar guna menghindari checkpoint I/O yang terlalu sering
innodb_log_file_size = 2G

# Batasi thread yang masuk secara bersamaan untuk mencegah lonjakan konteks switching CPU
thread_handling = one-thread-per-connection
max_connections = 500

# Mengatur agresivitas flushing ke disk
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
```

Konfigurasi di atas memastikan bahwa struktur *B-Tree* dari indeks Anda dapat disimpan langsung di dalam memori RAM yang super cepat, meminimalkan operasi pembacaan dari *Storage SSD NVMe* yang lambat.

## 4. Koleksi Mantra One-Liner Siap Salin untuk Keseharian

Sebagai *engineer*, kita menyukai efisiensi terminal. Berikut adalah kumpulan perintah *one-liner* SQL dan *bash* yang sering saya gunakan di lapangan untuk mendiagnosis dan mengeksekusi optimasi:

Menganalisis *Execution Plan* secara mendalam langsung dari CLI:
```sql
EXPLAIN FORMAT=JSON SELECT * FROM transactions WHERE user_id = 48291 AND status = 'completed'G
```

Mencari query lambat yang sedang berjalan secara *real-time* di MariaDB:
```sql
SELECT id, user, host, db, command, time, state, info FROM information_schema.processlist WHERE command != 'Sleep' ORDER BY time DESC;
```

Menjalankan *Analyze Table* untuk memperbarui statistik indeks setelah perubahan masif:
```sql
ANALYZE TABLE transactions PERSISTENT FOR ALL;
```

Mengecek ukuran fisik tabel dan indeks di dalam database:
```sql
SELECT table_name AS `Table`, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS `Size (MB)` FROM information_schema.TABLES WHERE table_schema = 'production_db' ORDER BY (data_length + index_length) DESC;
```

## 5. Jalur Bahaya: Dosa Besar yang Wajib Dihindari di Produksi

Banyak junior terjebak dalam mitos "makin banyak indeks, makin cepat aplikasi". Ini adalah **dosa besar pertama**. Membuat indeks pada setiap kolom justru akan menghancurkan performa operasi tulis (`INSERT`/`UPDATE`) karena MariaDB harus memperbarui seluruh struktur pohon indeks di latar belakang. Saya pernah melihat sebuah tabel *log* mengalami penurunan performa tulis hingga 800% hanya karena memiliki 14 indeks yang tidak pernah digunakan oleh query apa pun.

> [!WARNING]
> Jangan pernah menjalankan perintah `ALTER TABLE ... ADD INDEX` secara langsung pada tabel produksi berukuran puluhan juta baris tanpa menggunakan *online DDL* atau *pt-online-schema-change*. Perintah mentah tersebut akan mengunci tabel secara eksklusif dan membuat aplikasi web Anda langsung tumbang (*downtime* total).

Selalu periksa *Unused Indexes* menggunakan *Performance Schema* sebelum memutuskan menghapus atau menambah indeks baru. Pertahankan disiplin arsitektur ini, dan infrastruktur database Anda akan bernapas dengan lega bahkan di bawah beban jutaan pengguna.