9 Kesalahan SQL yang Bahkan Dilakukan oleh Developer Berpengalaman

"Kamu baru saja menggunakan SELECT * di production?"

Steve menatap saya seolah-olah saya baru saja menekan tombol self-destruct merah.

Kami sedang men-debug dashboard yang lambat pada pukul 2 pagi, dan performanya semakin menurun. Setelah 30 menit berperan sebagai detektif, kami menemukan pelakunya: sebuah query SQL yang ditulis dengan indah namun sangat tidak efisien — yang dibuat oleh saya sendiri.

Dan yang terburuk?

Saya pikir saya tahu apa yang saya lakukan.

Itulah masalah dengan SQL: tampak luar biasa sederhana. Tetapi seperti setumpuk kartu yang diacak dengan baik, SQL menyembunyikan kompleksitas di balik sintaksisnya yang bersih. Bahkan developer berpengalaman — orang-orang yang telah bekerja dengan SQL selama bertahun-tahun — terjebak dalam jebakan halus dan mahal.

Mari kita dalami. Berikut adalah kesalahan SQL paling umum yang bahkan dilakukan oleh developer berpengalaman, mengapa kesalahan tersebut penting, dan bagaimana memperbaikinya — secara nyata.

1. Menggunakan SELECT * Seolah-olah Tidak Berbahaya

Mengapa terjadi:

Cepat. Nyaman. Berhasil.

Mengapa ini menjadi masalah:

Menarik semua kolom meningkatkan beban jaringan
Membuat join lebih berat
Rusak ketika skema berubah
Mencegah optimasi query

Apa yang harus dilakukan sebagai gantinya:

Secara eksplisit sebutkan hanya kolom yang Anda butuhkan. Ini membantu performa, keterbacaan, dan stabilitas.


🚫 SELECT * FROM users
✅ SELECT id, name, email FROM users

Pro tip: Tambahkan linter ke alur kerja SQL Anda yang menandai SELECT * dalam review.

Contoh Kasus Nyata:

Bayangkan tabel users memiliki 30 kolom termasuk blob foto profil berukuran besar. Jika Anda hanya membutuhkan nama dan email untuk menampilkan daftar pengguna, menggunakan SELECT * akan memuat semua data foto profil yang tidak perlu, memperlambat aplikasi Anda dan membuang-buang bandwidth.

2. Mengabaikan Index (atau Menggunakannya Secara Membabi Buta)

Mengapa terjadi:

Banyak developer tahu index ada tetapi memperlakukannya seperti debu ajaib. Taburkan dan lupakan.

Mengapa ini menjadi masalah:

Index yang hilang → query lambat
Index yang salah → penulisan lambat
Terlalu banyak index → penyimpanan membengkak dan operasi INSERT lebih lambat

Apa yang harus dilakukan sebagai gantinya:

Pahami cara kerja index. Gunakan tools seperti EXPLAIN atau EXPLAIN ANALYZE untuk melihat apakah query Anda menggunakan index.

Perhatikan:

Query pada kolom WHERE yang tidak terindex
JOIN pada kunci yang tidak terindex
ORDER BY + LIMIT tanpa indexing yang tepat

Index yang baik seperti peta yang baik — harus mengarahkan query langsung ke tujuan.

Contoh Implementasi:


-- Tambahkan index pada kolom yang sering difilter
CREATE INDEX idx_users_email ON users(email);

-- Gunakan EXPLAIN untuk memverifikasi penggunaan index
EXPLAIN SELECT * FROM users WHERE email = 'user@example.com';

3. Mengasumsikan Query Berskala Linier

Mengapa terjadi:

Sindrom "Berjalan baik di laptop saya!"

Mengapa ini menjadi masalah:

Dataset tes Anda memiliki 500 baris. Production memiliki 50 juta. CTE yang Anda gunakan? Sekarang menjadi monster.

Apa yang harus dilakukan sebagai gantinya:

Selalu uji query pada data berukuran production
Gunakan pagination untuk hasil besar
Pantau log query lambat
Lakukan benchmark!

Sebuah query 200ms hari ini dapat menjadi timeout 10 detik besok.

Kasus Implementasi:

Alih-alih:


-- Berpotensi lambat pada dataset besar
SELECT * FROM orders ORDER BY created_at DESC;

Gunakan:


-- Dengan pagination untuk performa yang lebih baik
SELECT * FROM orders 
ORDER BY created_at DESC
LIMIT 100 OFFSET 200;

4. Menyalahgunakan JOIN (Terutama Dengan Kondisi yang Hilang)

Mengapa terjadi:

Anda terburu-buru. Anda menambahkan join. Berjalan. Anda melanjutkan.

Mengapa ini menjadi masalah:

Kondisi join yang hilang menyebabkan Cartesian product
Tipe join yang salah menyebabkan hasil yang tidak benar

Jebakan klasik:


SELECT * 
FROM orders
JOIN customers
-- Ups, tidak ada kondisi ON!

Itu baru saja mengalikan baris Anda dengan ribuan.

Solusi:

Selalu periksa kembali klausa ON Anda
Ketahui tipe JOIN Anda (INNER, LEFT, RIGHT, FULL)
Gunakan alias dengan jelas untuk menghindari kebingungan

Contoh Perbaikan:


SELECT o.order_id, c.customer_name 
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.order_date > '2025-01-01';

5. Terlalu Banyak Menggunakan Subquery Alih-alih JOIN atau CTE

Mengapa terjadi:

Subquery terasa lebih mudah untuk ditulis.

Mengapa ini menjadi masalah:

Sering menyebabkan pekerjaan redundan
Mesin SQL tidak selalu dapat mengoptimalkannya
Lebih sulit di-debug

Apa yang harus dilakukan sebagai gantinya:

Gunakan Common Table Expressions (CTE) atau join yang terstruktur dengan baik.

❌ Tidak Efisien:


SELECT name FROM users
WHERE id IN (SELECT user_id FROM purchases WHERE amount > 100)

✅ Lebih baik dengan JOIN:


SELECT u.name
FROM users u
JOIN purchases p ON u.id = p.user_id
WHERE p.amount > 100

Contoh CTE untuk Kasus Kompleks:


WITH high_value_purchases AS (
    SELECT user_id, SUM(amount) AS total_spent
    FROM purchases
    GROUP BY user_id
    HAVING SUM(amount) > 1000
)
SELECT u.name, h.total_spent
FROM users u
JOIN high_value_purchases h ON u.id = h.user_id
ORDER BY h.total_spent DESC;

6. Tidak Berpikir dalam Set

Mengapa terjadi:

Kebiasaan pemrograman imperatif merembes ke SQL. Anda berpikir baris demi baris.

Mengapa ini menjadi masalah:

SQL adalah bahasa deklaratif berbasis set. Menulis logika gaya prosedural (seperti loop atau penyalahgunaan cursor) menghasilkan query yang membengkak dan tidak dioptimalkan.

Apa yang harus dilakukan sebagai gantinya:

Bingkai ulang masalah Anda dalam hal apa yang Anda inginkan, bukan bagaimana mendapatkannya. Pelajari untuk memanfaatkan:

GROUP BY
HAVING
CASE
Window functions

Contoh: Alih-alih mengiterasi setiap pengguna untuk menemukan pesanan terbaru mereka, gunakan ROW_NUMBER().


WITH ranked_orders AS (
    SELECT 
        user_id, 
        order_id,
        order_date,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) AS rn
    FROM orders
)
SELECT 
    u.name, 
    r.order_id, 
    r.order_date
FROM users u
JOIN ranked_orders r ON u.id = r.user_id
WHERE r.rn = 1;

7. Mengabaikan Transaction dan Isolation Level

Mengapa terjadi:

Transaction terasa "enterprise-y." Sampai data Anda rusak.

Mengapa ini menjadi masalah:

Tidak menggunakan transaction = data tidak konsisten selama operasi multi-langkah
Menggunakan isolation default secara membabi buta = race condition, phantom read, dirty read

Apa yang harus dilakukan sebagai gantinya:

Bungkus query terkait dalam transaction
Pelajari isolation level yang berbeda (READ COMMITTED, REPEATABLE READ, SERIALIZABLE)
Pikirkan tentang konkurensi

Jika dua pengguna dapat mengupdate baris yang sama secara bersamaan, Anda perlu peduli dengan isolation.

Implementasi Praktis:


BEGIN TRANSACTION;

UPDATE accounts 
SET balance = balance - 100 
WHERE account_id = 123;

UPDATE accounts 
SET balance = balance + 100 
WHERE account_id = 456;

-- Verifikasi bahwa kedua update berhasil
COMMIT;

8. Tidak Menggunakan EXPLAIN atau Tool Profiling Query

Mengapa terjadi:

Orang-orang meremehkan seberapa lambat query dapat menjadi.

Mengapa ini menjadi masalah:

Tanpa wawasan, Anda hanya menebak apa yang salah. Dan DBA Anda diam-diam menilai Anda.

Apa yang harus dilakukan sebagai gantinya:

Gunakan EXPLAIN atau EXPLAIN ANALYZE secara teratur
Biasakan diri dengan istilah seperti "Seq Scan", "Index Scan", "Hash Join"
Gunakan log query lambat atau profiling bawaan di PostgreSQL, MySQL, atau cloud provider Anda

Contoh Penggunaan EXPLAIN:


-- PostgreSQL
EXPLAIN ANALYZE 
SELECT c.customer_name, SUM(o.total_amount) 
FROM customers c 
JOIN orders o ON c.id = o.customer_id 
WHERE c.region = 'Jakarta' 
GROUP BY c.customer_name;

Output EXPLAIN akan menunjukkan:

Apakah query menggunakan index
Bagian mana dari query yang paling mahal (time-consuming)
Estimasi jumlah baris yang harus diproses

9. Memperlakukan SQL Sebagai Pikiran Belakangan

Ini mungkin kesalahan paling berbahaya dari semuanya.

Mengapa terjadi:

Tim developer memprioritaskan logika aplikasi, bukan logika data. SQL ditambahkan belakangan. Buruk pengujiannya. Buruk dokumentasinya.

Mengapa ini menjadi masalah:

Keputusan data yang buruk akan menghantui Anda selamanya.

Apa yang harus dilakukan sebagai gantinya:

Perlakukan skema database Anda seperti kode: versi, review, uji
Tulis query yang dapat digunakan kembali dan modular
Dokumentasikan model data dan asumsi Anda
Libatkan data engineer atau DBA sejak awal

Anda menghabiskan lebih banyak waktu membaca SQL daripada menulisnya — buat itu mudah dibaca, efisien, dan disengaja.

Best Practice:

-- Gunakan komentar untuk menjelaskan query kompleks /* Analisis LTV (Lifetime Value) per pelanggan Menghitung total pembelanjaan, frekuensi pembelian, dan rata-rata nilai pesanan */ WITH customer_metrics AS ( SELECT customer_id, COUNT(*) AS total_orders, SUM(amount) AS total_spent, AVG(amount) AS avg_order_value FROM orders WHERE order_date > CURRENT_DATE - INTERVAL '1 year' GROUP BY customer_id ) SELECT c.name, c.segment, cm.total_orders, cm.total_spent, cm.avg_order_value FROM customers c JOIN customer_metrics cm ON c.id = cm.customer_id ORDER BY cm.total_spent DESC;

Kesimpulan

Kenyataannya? SQL bukan hanya bahasa query — ini adalah alat berpikir.

Jika Anda membangun sistem yang bergantung pada data (dan mari kita jujur, sistem apa yang tidak pada tahun 2025?), menulis SQL yang bersih dan berkinerja baik adalah superpower.

Bahkan developer berpengalaman terjebak dalam kebiasaan buruk. Tetapi dengan kesadaran, niat, dan beberapa kali menjalankan EXPLAIN, Anda dapat menulis SQL yang dapat diskalakan, bersinar, dan yang akan diapresiasi oleh diri Anda di masa depan.

Cheat Sheet:

Avoid SELECT *. Be intentional.
Index wisely — don’t overdo or underdo.
Don’t assume small queries scale.
Always define your joins properly.
Prefer CTEs and joins over nested subqueries.
Think in sets, not loops.
Use transactions and know your isolation levels.
Profile your queries.

Treat SQL like production code.

Glossary: Terminologi Penting untuk Data Analyst

SELECT: Klausa SQL untuk mengambil data dari database.
WHERE: Klausa untuk memfilter hasil query berdasarkan kondisi tertentu.
JOIN: Operasi untuk menggabungkan baris dari dua atau lebih tabel berdasarkan kolom terkait.
INDEX: Struktur data yang meningkatkan kecepatan operasi pengambilan data pada tabel database dengan mengorbankan penulisan dan ruang penyimpanan tambahan.
CTE (Common Table Expression): Pernyataan temporary yang dapat direferensikan dalam query untuk membuat query kompleks lebih mudah dibaca dan dipelihara.
Cartesian Product: Hasil dari JOIN tanpa kondisi yang menghasilkan semua kombinasi yang mungkin dari baris di kedua tabel, menyebabkan hasil query membengkak.
Window Function: Fungsi yang beroperasi pada set baris yang berhubungan dengan baris saat ini, memungkinkan perhitungan seperti running totals atau moving averages.
Transaction: Unit kerja tunggal yang harus diselesaikan seluruhnya atau tidak sama sekali, menjamin integritas data.
Isolation Level: Tingkat isolasi yang mengatur bagaimana transaksi berinteraksi dengan transaksi lain yang berjalan secara bersamaan.
EXPLAIN: Perintah yang menunjukkan rencana eksekusi query database, membantu mengidentifikasi dan memperbaiki masalah performa.
Execution Plan: Rangkaian langkah yang direncanakan oleh database untuk mengeksekusi query SQL.
Pagination: Teknik untuk membagi hasil query yang besar menjadi "halaman" yang lebih kecil dan lebih mudah dikelola.
Query Optimizer: Komponen database yang menentukan cara paling efisien untuk mengeksekusi query SQL.

Citations:

in Data Analyst

Satu Klausa SQL Ini Membuat Query Saya 10x Lebih Cepat