LIMIT<\/strong> \u2013 urutkan dan batasi hasil untuk menekan beban.<\/li>\n<\/ul>\n-- Query adalah perintah yang spesifik, bukan tebak-tebakan\r\nSELECT o.id, c.name, SUM(oi.qty * oi.price) AS total\r\nFROM orders o\r\nJOIN customers c ON c.id = o.customer_id\r\nJOIN order_items oi ON oi.order_id = o.id\r\nWHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days'\r\nGROUP BY o.id, c.name\r\nHAVING SUM(oi.qty * oi.price) >= 1000000\r\nORDER BY total DESC\r\nLIMIT 50;<\/code><\/pre>\nCatatan: indeks di orders.created_at<\/code>, order_items.order_id<\/code>, dan orders.customer_id<\/code> biasanya krusial untuk mencegah full scan.<\/p>\n<\/span>Query adalah tentang niat yang jelas<\/span><\/h3>\nSebelum menulis SELECT, tanyakan: \u201ckolom apa, dari tabel mana, dengan filter apa, dan urutan apa?\u201d Semakin tajam niatnya, semakin kecil hasil dan semakin cepat waktu respon. Ini berlaku di SQL maupun mesin pencari.<\/p>\n
<\/span>Query adalah lebih dari SQL: NoSQL, GraphQL, sampai REST<\/span><\/h2>\nArsitektur modern jarang mono-database. Kita sering ketemu kombinasi relational + dokumen + search. Cara menulis query pun ikut menyesuaikan.<\/p>\n
<\/span>Query adalah di document database<\/span><\/h3>\n\/\/ MongoDB: cari order 30 hari terakhir dengan total \u2265 1.000.000\r\ndb.orders.aggregate([\r\n { $match: { createdAt: { $gte: new Date(Date.now() - 30*24*3600*1000) } } },\r\n { $unwind: \"$items\" },\r\n { $group: { _id: \"$_id\", customerName: { $first: \"$customerName\" },\r\n total: { $sum: { $multiply: [\"$items.qty\", \"$items.price\"] } } } },\r\n { $match: { total: { $gte: 1000000 } } },\r\n { $sort: { total: -1 } },\r\n { $limit: 50 }\r\n]);<\/code><\/pre>\nDi dokumen store, denormalisasi itu wajar. Tapi awasi ukuran dokumen agar tidak membengkak (impact ke memory dan I\/O).<\/p>\n
<\/span>Query adalah di GraphQL<\/span><\/h3>\n# Ambil order dan 3 item teratasnya\r\nquery TopOrders($from: DateTime!, $minTotal: Int!) {\r\n orders(from: $from, minTotal: $minTotal, limit: 50) {\r\n id\r\n customer { name }\r\n items(limit: 3) { sku qty price }\r\n total\r\n }\r\n}<\/code><\/pre>\nGraphQL memaksa kita eksplisit soal \u201cmedan\u201d (field) yang diminta\u2014bagus untuk mengendalikan payload. Tapi tetap butuh backend resolver yang efisien.<\/p>\n
<\/span>Query adalah parameter di REST<\/span><\/h3>\nGET \/orders?from=2025-09-22&min_total=1000000&limit=50&sort=total_desc<\/code><\/pre>\nKelihatannya simpel, tapi tetap perlu pagination, sorting yang konsisten, dan validasi parameter untuk mencegah abuse.<\/p>\n
<\/span>Arsitektur eksekusi: dari parser ke optimizer<\/span><\/h2>\nDi balik layar, mesin database mem-parsing query, menyusun rencana eksekusi (query plan<\/em>), lalu mengeksekusi. Optimizer memilih strategi: pakai indeks atau scan, urutan join, dan algoritma agregasi. Gunakan EXPLAIN<\/code> untuk membaca rencana eksekusi\u2014ini cara paling nyata memahami kenapa sebuah query lambat.<\/p>\nEXPLAIN ANALYZE\r\nSELECT ...; -- lihat apakah pakai Index Scan, Seq Scan, Hash Join, Nested Loop, dll.<\/code><\/pre>\nKalau plan menunjukkan Seq Scan<\/em> di tabel besar, biasanya sinyal perlu indeks atau perbaikan filter.<\/p>\n<\/span>Index, cache, dan strategi bikin query adalah cepat<\/span><\/h2>\n\n- Index yang relevan<\/strong> \u2013 Index di kolom filter dan join. Untuk rentang waktu, pertimbangkan indeks komposit (
created_at, customer_id<\/code>).<\/li>\n- Covering index<\/strong> \u2013 Pastikan kolom yang diambil tersedia di indeks agar menghindari lookup ke tabel utama.<\/li>\n
- Partial index<\/strong> \u2013 Index subset data yang sering diakses (misalnya status \u201cactive\u201d).<\/li>\n
- Cache<\/strong> \u2013 Response caching (HTTP), query cache di aplikasi, atau Redis untuk hasil yang sering dipakai ulang.<\/li>\n
- Pagination benar<\/strong> \u2013 Hindari
OFFSET<\/code> besar; gunakan keyset pagination<\/em> (berdasar penanda terakhir).<\/li>\n<\/ul>\n<\/span>Perbandingan bahasa query populer<\/span><\/h2>\n\n\n\n| Bahasa<\/th>\n | Kegunaan<\/th>\n | Kelebihan<\/th>\n | Keterbatasan<\/th>\n | Contoh<\/th>\n<\/tr>\n<\/thead>\n |
\n\n| SQL<\/td>\n | Relational\/OLTP\/OLAP<\/td>\n | Standar, kuat di join & agregasi<\/td>\n | Rigid bila skema sering berubah<\/td>\n | SELECT ... WHERE ... JOIN ...<\/code><\/td>\n<\/tr>\n\n| Aggregation (Mongo)<\/td>\n | Dokumen semi-terstruktur<\/td>\n | Skema fleksibel, pipeline kaya<\/td>\n | Join lintas koleksi terbatas<\/td>\n | $match \u2192 $group \u2192 $sort<\/code><\/td>\n<\/tr>\n\n| GraphQL<\/td>\n | API dengan field terkontrol<\/td>\n | Hanya ambil field yang perlu<\/td>\n | Resolver rentan N+1<\/td>\n | query { orders { id total } }<\/code><\/td>\n<\/tr>\n\n| Lucene DSL<\/td>\n | Full-text & logs<\/td>\n | Cepat untuk pencarian teks<\/td>\n | Eventual consistency<\/td>\n | {\"match\":{\"title\":\"camera\"}}<\/code><\/td>\n<\/tr>\n\n| Cypher\/Gremlin<\/td>\n | Graf relasi<\/td>\n | Traversal multi-hop efisien<\/td>\n | Kalkulasi tabular massal kurang pas<\/td>\n | MATCH (a)-[:FRIEND]->(b)<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/span>Optimasi praktis: pola bikin query adalah gesit<\/span><\/h2>\n\n- Ambil seperlunya<\/strong> \u2013 pilih kolom yang dibutuhkan, batasi baris dengan
WHERE<\/code> yang spesifik.<\/li>\n- Letakkan filter di sisi yang terindeks<\/strong> \u2013 type dan urutan kolom indeks memengaruhi kecepatan.<\/li>\n
- Hindari wildcard di depan<\/strong> \u2013
LIKE '%abc'<\/code> sulit pakai indeks; pertimbangkan full-text index.<\/li>\n- Materialized view<\/strong> \u2013 untuk agregasi berat yang diakses berulang.<\/li>\n
- Denormalisasi seperlunya<\/strong> \u2013 simpan ringkasan\/total untuk mempercepat read, update di jalur tulis.<\/li>\n<\/ol>\n
<\/span>Anti-pattern yang bikin query adalah lambat<\/span><\/h2>\n\n- SELECT *<\/strong> \u2013 bengkak payload, menghambat index-only scan.<\/li>\n
- JOIN tanpa key jelas<\/strong> \u2013 memicu nested loop raksasa.<\/li>\n
- Fungsi di kolom terindeks<\/strong> \u2013
WHERE LOWER(email)=...<\/code> menonaktifkan indeks biasa; gunakan indeks fungsional bila tersedia.<\/li>\n- Offset besar<\/strong> \u2013 halaman 5000 itu mahal; pakai keyset pagination dengan penanda last seen<\/em>.<\/li>\n
- Filter low selectivity<\/strong> \u2013 nilai yang muncul di hampir semua baris membuat indeks kurang berguna.<\/li>\n<\/ul>\n
<\/span>Observability: buktikan, jangan menebak<\/span><\/h2>\nGunakan slow query log, tracing (mis. OpenTelemetry), dan dashboard metrik. Ukur p95\/p99 latency, throughput, cache hit ratio. Sering kali bottleneck bukan di database, melainkan di lapisan API atau jaringan. Data nyata mencegah optimasi \u201cfeeling\u201d.<\/p>\n | | | | |