Fungsi QUERY di Google Sheets mendukung delapan jenis klausa dari Google Visualization API Query Language (GQL): SELECT, WHERE, GROUP BY, PIVOT, ORDER BY, LIMIT, OFFSET, dan LABEL. Yang tidak didukungnya - dan ini sering menjebak analis berpengalaman sekalipun - adalah subquery, window function, JOIN lintas range, dan penanganan nilai NULL yang konsisten. Keempat celah inilah yang membuat fungsi ini rontok ketika dihadapkan pada model keuangan nyata, dan penting untuk Anda pahami sebelum membangun sesuatu yang bergantung padanya.
Apa yang Didukung Fungsi QUERY Google Sheets
Daftar klausa yang tersedia terdokumentasi di referensi Google Visualization API Query Language. Per April 2026, cakupannya adalah:
| Klausa | Fungsi | Bekerja lintas tab? |
|---|---|---|
SELECT | Memilih dan mengurutkan ulang kolom | Ya |
WHERE | Memfilter baris berdasarkan kondisi | Ya |
GROUP BY | Agregasi dengan SUM, AVG, COUNT, MAX, MIN | Ya |
PIVOT | Membuat tabulasi silang nilai | Ya, dengan catatan |
ORDER BY | Mengurutkan data naik atau turun | Ya |
LIMIT | Membatasi jumlah baris output | Ya |
OFFSET | Melewati sejumlah baris awal | Ya |
LABEL | Mengganti nama kolom di output | Ya |
Contoh kasus nyata untuk tim FP&A: menarik seluruh transaksi di atas Rp 500 juta dari buku besar umum (general ledger) yang berisi lebih dari 20.000 baris, lalu mengelompokkannya per cost center - tanpa kolom bantu, tanpa range perantara.
=QUERY('GL Detail'!A:F,
"SELECT B, SUM(F)
WHERE F > 500000000
GROUP BY B
ORDER BY SUM(F) DESC
LABEL SUM(F) 'Total Pengeluaran'",
1)
Referensi lintas tab bekerja normal - 'GL Detail'!A:F adalah sintaks standar. Cara QUERY membaca kolom secara internal (Col1, Col2, dan seterusnya, atau referensi huruf kolom tergantung cara Anda memanggilnya) dibahas secara terpisah di artikel tentang sintaks QUERY Col1 Col2.
Klausa PIVOT layak mendapat perhatian khusus. Klausa ini sangat berguna untuk mengubah tabel transaksi datar menjadi matriks bergaya P&L tanpa harus membuat pivot table. Kendalanya: nilai kolom pivot harus sudah diketahui saat formula ditulis, dan kolom output muncul secara dinamis - artinya formula di hilir yang mereferensikan kolom tertentu berdasarkan posisi akan rusak ketika data berubah. Untuk paket laporan ke direksi atau investor, hal ini sangat krusial.
Apa yang Tidak Dicakup Fungsi QUERY Google Sheets
Bagian ini lebih penting bagi siapa pun yang membangun model multi-tab. Spesifikasi GQL memperjelas apa saja yang dikecualikan:
Subquery. Anda tidak bisa menyarangkan satu QUERY di dalam QUERY lainnya. Jika Anda ingin memfilter berdasarkan hasil agregasi - misalnya, hanya cost center dengan total pengeluaran melebihi Rp 10 miliar - Anda perlu pendekatan dua langkah: QUERY pertama ke range bantu, lalu QUERY kedua pada range tersebut. Merepotkan, tapi bisa berjalan.
Window function. Tidak ada ROW_NUMBER(), tidak ada RANK(), tidak ada running total via OVER PARTITION BY. Untuk analisis contribution margin yang diurutkan per SKU, Anda harus menarik data ke kolom bantu atau menerima kenyataan bahwa QUERY tidak bisa melakukannya secara native.
JOIN lintas range. QUERY hanya beroperasi pada satu range yang berdampingan. Anda tidak bisa menggabungkan 'P&L'!A:D dengan 'Headcount'!A:C dalam satu panggilan QUERY. Solusi yang paling umum dipakai analis adalah konkatenasi array {range1, range2} untuk menggabungkan dua range menjadi satu sebelum di-query - yang mensyaratkan jumlah baris yang sama dan menghasilkan referensi kolom yang rapuh.
Penanganan NULL. GQL memperlakukan sel kosong sebagai null, tetapi tidak mempropagasikannya secara konsisten melalui semua agregasi. SUM mengabaikan null dengan benar; AVG juga demikian. Namun sintaks WHERE Col3 is null bekerja tidak konsisten tergantung apakah sel tersebut benar-benar kosong atau mengandung string panjang nol. Dalam praktiknya, tambahkan pembungkus IFERROR dan uji pada sampel data sebelum mengandalkan filter null di lingkungan produksi.
Sebagai gambaran performa: QUERY yang merangkum 50.000 baris transaksi menjadi ringkasan 30 baris per cost center berjalan dalam waktu kurang dari 2 detik di instance Sheets modern. Performa bukan hambatannya - batasan struktural inilah yang perlu Anda waspadai.
Menulis Formula QUERY yang Tidak Mudah Rusak
Modus kegagalan paling umum dalam model dengan 8 tab yang saling terhubung adalah formula QUERY yang mereferensikan posisi kolom (Col1, Col2) alih-alih huruf kolom. Ketika seseorang menyisipkan kolom di tab sumber, setiap QUERY berbasis posisi akan bergeser secara diam-diam tanpa peringatan.
Gunakan huruf kolom saat melakukan query pada named range atau referensi tab dengan skema yang stabil:
=QUERY(INDIRECT("'P&L'!A:H"),
"SELECT A, C, D
WHERE C >= " & Asumsi!$B$3 & "
AND D <> ''
ORDER BY A",
1)
Cutoff tanggal yang dinamis - seperti menarik data aktual hingga tanggal penutupan laporan triwulanan - bekerja dengan cara mengonkatenasi nilai referensi sel ke dalam string query. Pola Asumsi!$B$3 di atas adalah cara yang tepat. Jangan hardcode tanggal langsung ke dalam string query.
Klausa LABEL sering diabaikan. Klausa ini mengganti nama kolom output tanpa menyentuh data sumber, sehingga header tabel di laporan Anda tetap rapi meski nama kolom di sumber adalah singkatan berkode. Manfaatkan ini:
=QUERY('Pendapatan'!A:E,
"SELECT B, SUM(E)
WHERE A = 'Q1'
GROUP BY B
LABEL B 'Unit Bisnis', SUM(E) 'Pendapatan Q1 (Rp)'",
1)
Untuk model multi-tab: jika Anda sering melakukan query lintas sheet, konsolidasikan data sumber ke dalam satu tab staging terlebih dahulu. Satu QUERY pada range staging 20.000 baris jauh lebih baik kinerjanya dibanding enam QUERY pada enam tab terpisah - baik dari sisi kecepatan maupun kemudahan debugging.
Kapan QUERY Bukan Lagi Alat yang Tepat
Keterbatasan JOIN adalah jawaban jujur atas pertanyaan "kapan saya harus berhenti menggunakan QUERY." Jika analisis Anda perlu merekonsiliasi dua dataset - misalnya, mencocokkan 3.400 faktur dari tab 'AP' dengan catatan pembayaran di tab 'Treasury' berdasarkan ID faktur - QUERY tidak bisa melakukannya. INDEX/MATCH menangani lookup satu-ke-satu; SUMIFS menangani lookup teragregasi; tetapi join relasional membutuhkan kolom bantu atau sesuatu di luar sintaks QUERY native.
Batasan lain yang sering muncul dalam praktik: mengagregasi data lintas sheet dengan skema berbeda. QUERY tidak bisa secara dinamis menggabungkan range dari 'Jan'!A:F, 'Feb'!A:F, 'Mar'!A:F kecuali Anda mengonkatenasikannya secara eksplisit dengan {'Jan'!A:F; 'Feb'!A:F; 'Mar'!A:F} - dan cara ini menjadi tidak terkelola jika tabnya sudah banyak.
Integrasi DuckDB dari ModelMonkey menangani kasus-kasus ini dengan mengizinkan Anda menjalankan SQL sungguhan terhadap range sheet, termasuk join lintas tab. Sintaksnya dalam praktik terlihat seperti ini:
SELECT ap.invoice_id, ap.amount, t.payment_date
FROM sheet_range('AP!A:D') ap
JOIN sheet_range('Treasury!A:C') t ON ap.invoice_id = t.invoice_id
WHERE ap.amount > 100000000
Itulah jalan keluarnya ketika keterbatasan QUERY mulai menguras waktu Anda. Artikel tentang integrasi Google Sheets dengan DuckDB membahas cara pengaturannya secara lengkap.
FAQ: Fungsi QUERY Google Sheets
Apakah QUERY Google Sheets mendukung subquery?
Tidak. GQL tidak mengizinkan satu QUERY bersarang di dalam QUERY lainnya. Alternatif yang paling praktis adalah pendekatan dua langkah: jalankan QUERY pertama ke range atau tab bantu, lalu jalankan QUERY kedua pada hasil tersebut. Cara ini lebih banyak makan tempat di spreadsheet, tetapi berfungsi dengan baik untuk sebagian besar kebutuhan analisis.
Berapa batas baris yang bisa diproses fungsi QUERY?
Tidak ada batas baris yang didokumentasikan secara resmi oleh Google untuk fungsi QUERY. Dalam praktik, QUERY yang merangkum 50.000 baris menjadi 30 baris ringkasan berjalan dalam waktu kurang dari 2 detik di Google Sheets modern. Bottleneck performa biasanya bukan dari QUERY itu sendiri, melainkan dari banyaknya formula volatile (seperti NOW() atau INDIRECT) yang memicu kalkulasi ulang seluruh sheet secara bersamaan.
Kapan sebaiknya tidak menggunakan QUERY di Google Sheets?
Ada tiga situasi yang menjadi tanda untuk beralih ke alat lain. Pertama, ketika Anda perlu menggabungkan dua dataset berbeda berdasarkan kunci (join) - QUERY tidak mendukung ini secara native. Kedua, ketika Anda membutuhkan window function seperti ranking atau running total per segmen. Ketiga, ketika data sumber tersebar di banyak tab dengan skema berbeda dan jumlahnya terus bertambah - konkatenasi array manual yang diperlukan akan menjadi rapuh dan sulit dikelola seiring waktu.
Apakah referensi kolom di QUERY akan bergeser jika kolom disisipkan di sheet sumber?
Ya, jika Anda menggunakan notasi posisi (Col1, Col2, dst.). Notasi ini merujuk pada urutan kolom dalam range yang diberikan ke QUERY, bukan pada kolom spreadsheet yang sebenarnya - sehingga menyisipkan kolom baru di sheet sumber akan menggeser semua referensi posisi secara diam-diam tanpa pesan error. Gunakan notasi huruf kolom (A, B, C) dan pertahankan skema tab sumber agar tetap stabil untuk menghindari masalah ini.