UNESA
magetanteknikinformatika@unesa.ac.id

Analisis Proses Eksekusi Query dalam Sistem Database Relasional

Analisis Proses Eksekusi Query dalam Sistem Database Relasional

- kategori Akademik 56 Views

Kata Kunci: Query, SQL, Database, Eksekusi, Optimasi
Oleh: Renza Alvianino (NIM 24111814011)
Program Studi Informatika — Universitas Negeri Surabaya Kampus 5

Pendahuluan

Saat mengetik SELECT * FROM users;, hasilnya sering muncul sekejap. Di balik layar, database seperti MySQL melewati rangkaian proses: memahami maksud perintah, memilih rencana paling efisien, lalu mengeksekusinya. Mengerti alur ini membantu kita menulis query yang lebih cepat, hemat sumber daya, dan mudah di-debug—terutama saat aplikasi sudah melayani banyak pengguna.

Tahap 1 — Parsing & Validasi

Langkah pertama, database membaca query dan memeriksa dua hal: (1) sintaks—apakah penulisannya sah; dan (2) objek—apakah tabel/kolom memang ada. Kalau ada yang tidak cocok, langsung error. Jika lolos, query diubah menjadi struktur internal (parse tree) agar mesin “paham” apa yang diminta. Di sini constraint dasar (tipe data, not null) juga mulai berperan: lebih cepat gagal di awal daripada mengeksekusi sesuatu yang keliru.

Tahap 2 — Optimisasi

Bagian paling penting ada di optimizer. Tugasnya: membandingkan berbagai rute eksekusi, lalu memilih yang paling murah biayanya. Beberapa hal yang dipertimbangkan:

• Statistik & Kardinalitas — database menyimpan statistik (distribusi nilai kolom, jumlah baris, dsb.). Dari sini diperkirakan kardinalitas—berapa baris yang mungkin cocok. Perkiraan ini memengaruhi pilihan indeks dan urutan join.
• Strategi Join — nested loop, hash join, hingga merge join (bergantung mesin). Ukuran tabel dan selektivitas filter menentukan mana yang paling efisien.
• Pemakaian Indeks — indeks yang tepat memangkas pembacaan dari ribuan baris menjadi puluhan; indeks komposit (mis. (city, created_at)) sering lebih efektif ketimbang single column.
• Filter Pushdown & Proyeksi — menyaring sedini mungkin dan hanya mengambil kolom yang dibutuhkan (hindari SELECT *) mengurangi I/O.
• Biaya I/O vs CPU — optimizer menimbang trade-off: full scan mungkin murah untuk tabel kecil tapi mahal untuk tabel besar.

Hasil proses ini adalah execution plan—semacam “peta rute” yang akan dipakai mesin eksekusi.

Tahap 3 — Eksekusi

Setelah rencana dipilih, mesin menjalankannya langkah demi langkah. Jika ada indeks yang bisa dimanfaatkan, mesin “melompat” langsung ke lokasi data; kalau tidak, ia akan memindai blok demi blok. Hasilnya dikirim ke aplikasi atau terminal. Pada beban nyata, caching buffer pool juga membantu: data yang sering diakses bisa dilayani dari memori, bukan disk.

Contoh Praktis: EXPLAIN

Coba jalankan:

EXPLAIN SELECT name
FROM customers
WHERE city = 'Jakarta';

Perhatikan kolom seperti type, key, rows, dan Extra.

• key = NULL + type = ALL → biasanya full table scan.
• key = idx_city dan rows jauh lebih kecil → indeks bekerja baik.

EXPLAIN bukan sekadar formalitas; ia adalah “röntgen” untuk mengetahui apakah query kita sehat atau boros.

Transaksi, Locking, dan Isolasi

Di aplikasi nyata, satu query jarang berdiri sendiri. Ada transaksi yang mengelompokkan beberapa operasi sekaligus—ini terkait ACID. Mesin seperti InnoDB menggunakan MVCC untuk menjaga konsistensi bacaan sambil meminimalkan lock yang saling mengganggu. Level isolasi (READ COMMITTED, REPEATABLE READ, SERIALIZABLE) memengaruhi fenomena seperti phantom read. Pilih level yang pas dengan kebutuhan—semakin ketat, biasanya semakin berat biayanya.

Anti-Pattern Umum (dan Perbaikannya)

• SELECT * di tabel besar — ambil hanya kolom yang diperlukan.
• Filter di fungsi — WHERE DATE(created_at)=... membuat indeks sulit dipakai; ganti jadi rentang waktu:
created_at >= '2025-11-01' AND created_at < '2025-12-01'.
• Indeks kebanyakan/tidak relevan — terlalu banyak indeks memperlambat INSERT/UPDATE; audit indeks secara berkala.
• OFFSET besar untuk paginasi — gunakan keyset pagination (berbasis penanda terakhir) agar tidak mahal di halaman tinggi.

Indeks: Kapan & Bagaimana

• Kolom dengan selektivitas tinggi (nilai unik/nyaris unik) cocok untuk indeks.
• Indeks komposit harus mengikuti urutan pemakaian di WHERE/ORDER BY.
• Covering index (indeks mencakup semua kolom yang dibutuhkan) dapat menghindari akses ke tabel utama.

Observabilitas Ringan: Query Plan & Profiling

Selain EXPLAIN, gunakan EXPLAIN ANALYZE (jika tersedia) atau profiling untuk melihat waktu nyata tiap langkah eksekusi. Ini membantu mendeteksi bias statistik (mis. prediksi 100 baris, kenyataannya 1 juta) yang membuat rencana eksekusi meleset.

Mengapa Semua Ini Penting?

Satu query yang buruk dapat menjadi bottleneck di produksi. Dengan memahami parsing–optimisasi–eksekusi, kita bisa menulis query yang tepat sasaran, menemukan akar masalah kinerja lebih cepat, dan menghemat sumber daya (CPU, memori, I/O).

Checklist Cepat Saat Query Melambat

  1. Cek EXPLAIN: indeks dipakai atau tidak?

  2. Evaluasi filter & urutan join: bisa dipush-down/diubah urutannya?

  3. Audit indeks: cukup dan relevan?

  4. Tinjau paginasi & sorting: bisa pakai keyset atau covering index?

  5. Lihat statistik: sudah ANALYZE/uptodate? Statistik basi dapat menyesatkan optimizer.

Kesimpulan

Query SQL bukan sekadar kalimat singkat. Ia menempuh perjalanan: diverifikasi, dioptimalkan, lalu dieksekusi. Dengan memahami setiap tahap, kita bisa membuat aplikasi lebih cepat dan stabil—serta menghindari kejutan tidak menyenangkan di jam sibuk.

Daftar Pustaka (ringkas & relevan)

  1. “Understanding SQL Query Execution — What Happens When You Run a SQL Query.” TechTFQ, 2024.

  2. “Use MySQL EXPLAIN for Query Optimization.” Programming with Mosh, 2023.

  3. “How to Understand SQL EXPLAIN Query Plans.” CodingWithMax, 2023.

  4. “MySQL Query Execution Process Explained.” The Engineering World, 2023.

  5. “How to Speed Up Your Queries with Indexes.” Prisma, 2023.



Scroll to Top