Urutan Eksekusi Logis SELECT

Pertanyaan

"Kita menulis query dari SELECT dulu, tapi database tidak memprosesnya dengan urutan itu. Jelaskan urutan eksekusi logis sebuah query SELECT, dan apa akibatnya buat cara kita menulis query."

Tabel pesanan sebagai ilustrasi:

Jawaban Singkat

Urutan logisnya: FROM (termasuk JOIN), WHERE, GROUP BY, HAVING, SELECT (termasuk window function), DISTINCT, ORDER BY, lalu LIMIT. Akibatnya, alias yang dibuat di SELECT belum dikenal di WHERE, agregat tidak boleh di WHERE (pakai HAVING), dan window function tidak bisa difilter di WHERE. Sebaliknya ORDER BY datang setelah SELECT, jadi boleh memakai alias.

Pembahasan

Ikuti query di bawah sesuai urutan itu:

1. FROM pesanan: 8 baris.
2. WHERE status = 'selesai': pesanan 3 dan 6 (batal) dibuang, sisa 6 baris.
3. GROUP BY kota: Jakarta (250000 + 400000), Bandung (150000 + 120000), Surabaya (500000 + 200000).
4. HAVING SUM(total) > 300000: Bandung (270000) gugur.
5. SELECT: muncul kolom kota dan alias revenue.
6. ORDER BY revenue DESC: alias revenue sudah ada, jadi boleh dipakai di sini.
7. LIMIT 2: ambil dua teratas.

Kata "logis" penting: optimizer boleh mengeksekusi secara fisik dengan urutan lain (misalnya mendorong filter lebih awal), asalkan hasilnya sama dengan urutan logis ini.

Query

Salin
SELECT
  kota,
  SUM(total) AS revenue
FROM pesanan
WHERE status = 'selesai'
GROUP BY kota
HAVING SUM(total) > 300000
ORDER BY revenue DESC
LIMIT 2;

Contoh Output

Jebakan Umum

• Menulis WHERE revenue > 300000 memakai alias dari SELECT. Di PostgreSQL, MySQL, dan BigQuery ini error karena WHERE diproses sebelum alias dibuat (DuckDB memaafkannya, tapi jangan jadikan kebiasaan).
• Menaruh SUM(total) > 300000 di WHERE. Agregat belum dihitung pada tahap WHERE, jadi error.
• Memfilter ROW_NUMBER() OVER (...) = 1 di WHERE. Window function baru dihitung di tahap SELECT; bungkus dulu dengan CTE atau subquery.
• Mengira LIMIT dijalankan sebelum ORDER BY. Kalau begitu, hasil "top 2" jadi acak.

Follow-up dari Interviewer

• "Di mana posisi window function?" Dihitung di tahap SELECT, setelah WHERE, GROUP BY, dan HAVING. Karena itu window function bisa membungkus agregat, misalnya SUM(SUM(total)) OVER ().
• "Kenapa ORDER BY boleh pakai alias tapi GROUP BY tidak?" Menurut standar, GROUP BY diproses sebelum SELECT. Banyak engine tetap mengizinkan alias di GROUP BY sebagai kemudahan, tapi itu ekstensi, bukan konsekuensi urutan logis. Jangan bergantung pada itu di interview.
• "Apakah database benar-benar menjalankan FROM dulu?" Secara logis iya. Secara fisik optimizer bisa menyusun ulang (predicate pushdown, join reordering), tapi hasil akhirnya harus sama.

Yang Sebenarnya Diuji

Model mental tentang cara SQL bekerja. Hampir semua error klasik (alias di WHERE, agregat di WHERE, window function di WHERE) bisa dijelaskan dari urutan ini, jadi interviewer memakainya untuk mengukur seberapa dalam pemahamanmu.

Catatan Dialect

• DuckDB cukup longgar: alias SELECT bahkan boleh dipakai di WHERE, GROUP BY, dan HAVING. Ini kemudahan khusus DuckDB, bukan standar.
• MySQL dan BigQuery mengizinkan alias di GROUP BY dan HAVING, tapi tidak di WHERE. PostgreSQL mengizinkannya di GROUP BY saja.
• Supaya query portabel, anggap alias hanya aman di ORDER BY.
• DuckDB, BigQuery, dan Snowflake punya QUALIFY, tahap filter tambahan setelah window function dihitung.