Visualisasi query lambat dengan SQL histogram tidak harus dimulai dari dashboard besar. Untuk banyak tim backend, ringkasan teks di terminal, CI job, atau laporan harian sudah cukup untuk menjawab pertanyaan inti: query mana yang paling mahal, pola latensinya seperti apa, apakah data tumbuh tidak seimbang, dan index mana yang sebenarnya tidak membantu.

Pendekatan ini berguna ketika Anda ingin keputusan cepat tanpa biaya operasional tambahan. Dengan mengubah output EXPLAIN, slow query log, distribusi durasi, cardinality, dan hasil audit index menjadi bar teks sederhana, tim bisa membaca tren performa langsung dari terminal atau pull request. Inspirasi visualnya mirip gagasan “teks sebagai chart”: bukan dashboard penuh, tetapi representasi yang padat, murah, dan mudah dibagikan.

Mengapa histogram teks efektif untuk audit performa SQL

Masalah performa database sering tersembunyi dalam angka mentah: ratusan baris log, hasil EXPLAIN yang panjang, dan statistik index yang sulit dibaca cepat. Histogram atau bar teks membantu mengubah angka-angka itu menjadi pola visual yang langsung terlihat.

  • Distribusi durasi query: apakah mayoritas query cepat tetapi ada ekor lambat, atau semua query konsisten lambat.
  • Pertumbuhan data: tabel mana yang melonjak dan berpotensi mengubah rencana query.
  • Selektivitas index: cardinality rendah sering berarti index tidak banyak membantu filter.
  • Audit index komposit: urutan kolom yang salah sering membuat query tetap banyak membaca baris.

Keunggulan utamanya adalah signal-to-noise ratio. Dalam laporan teks, satu blok histogram sering lebih mudah dipahami daripada tabel 200 baris.

Metrik yang perlu dicatat

Sebelum membuat visual, tentukan metrik yang benar-benar berguna untuk pengambilan keputusan. Jangan hanya mengumpulkan apa yang mudah didapat.

1. Metrik slow query

  • Fingerprint query atau bentuk query yang sudah dinormalisasi.
  • Jumlah eksekusi.
  • Durasi minimum, median/p50, p95, maksimum.
  • Total waktu kumulatif.
  • Rows examined dan rows sent.
  • Waktu terjadinya, agar bisa dikaitkan dengan deploy atau lonjakan traffic.

2. Metrik hasil EXPLAIN

  • Jenis akses: ALL, range, ref, atau setara sesuai mesin database.
  • Index yang dipilih dan index yang tersedia.
  • Estimasi jumlah baris yang dibaca.
  • Filter atau predicate yang digunakan.
  • Informasi tambahan seperti sorting, temporary table, atau file sort bila tersedia.

3. Metrik audit index

  • Nama index dan urutan kolom.
  • Cardinality per kolom atau estimasi selektivitas.
  • Apakah index dipakai oleh query penting.
  • Index yang duplikat atau tumpang tindih.
  • Index yang jarang dipakai tetapi mahal saat write.

4. Metrik pertumbuhan data

  • Jumlah baris per tabel per hari atau per minggu.
  • Ukuran data dan index.
  • Distribusi nilai pada kolom yang sering difilter, misalnya status, tenant_id, atau created_at.

Catatan: angka estimasi dari optimizer tidak selalu sama dengan kondisi nyata. Karena itu, gabungkan hasil EXPLAIN dengan slow query log dan metrik runtime. Estimasi tanpa validasi runtime sering menyesatkan.

Sumber data yang bisa dipakai

Slow query log

Ini sumber paling praktis untuk menemukan query yang benar-benar lambat di produksi. Anda bisa mengekstrak durasi, rows examined, dan query text, lalu mengelompokkan query berdasarkan fingerprint.

EXPLAIN atau EXPLAIN ANALYZE

Gunakan untuk memahami mengapa query lambat. Fokus pada jalur akses, jumlah baris yang dibaca, dan apakah filter, sort, atau join memanfaatkan index dengan benar. Bila database Anda mendukung mode yang mengeksekusi query sambil memberi statistik aktual, itu biasanya lebih informatif daripada estimasi murni.

Metadata schema dan statistik index

Ambil dari katalog sistem atau informasi schema. Tujuannya bukan hanya mencatat index yang ada, tetapi juga mengevaluasi apakah index itu cocok dengan pola query nyata.

Mengubah output SQL menjadi histogram teks

Bentuk visual paling sederhana adalah bar horizontal berbasis karakter. Format ini stabil untuk terminal, log file, chat ops, dan laporan teks.

Contoh histogram distribusi durasi query

Misalnya Anda mengelompokkan durasi query API daftar transaksi menjadi bucket berikut:

<10ms     | #######  1420
10-50ms   | ########### 2211
50-100ms  | #####  1032
100-300ms | ###  611
300ms+    | ########  1504

Dari bentuk ini, Anda langsung melihat ekor lambat besar pada bucket 300ms+. Tanpa membaca log mentah, tim sudah tahu bahwa masalah bukan hanya rata-rata, tetapi tail latency.

Contoh visual rows examined vs rows returned

orders list by customer_id
returned:  | # 50
examined:  | ############################ 18000
ratio: 360:1

Rasio tinggi seperti ini sering menandakan filter tidak selektif, index tidak cocok, atau query melakukan scan terlalu luas.

Contoh visual cardinality index

Index audit: idx_orders_status_created
status      | ## low cardinality
created_at  | ############ medium-high cardinality

Visual ini membantu menjelaskan mengapa index yang dimulai dari status sering buruk: kolom pertama terlalu sedikit variasinya, sehingga optimizer tetap harus membaca banyak baris.

Query nyata yang sering jadi bottleneck

1. OFFSET besar pada paginasi

Query dengan LIMIT ... OFFSET ... besar terlihat sederhana, tetapi database tetap harus melewati banyak baris sebelum mengembalikan hasil.

SELECT id, customer_id, created_at, total
FROM orders
WHERE tenant_id = 42
ORDER BY created_at DESC
LIMIT 50 OFFSET 100000;

Masalahnya bukan hanya sorting, tetapi juga biaya membuang 100000 baris pertama. Jika dataset tumbuh, latensi biasanya naik hampir linear terhadap offset besar.

Visual yang membantu

Pagination latency by offset
0-1k       | ##
1k-10k     | ####
10k-50k    | ########
50k-100k   | #############
100k+      | ####################

Solusi yang biasanya lebih baik

Gunakan keyset pagination atau seek method, misalnya berdasarkan created_at dan id sebagai penanda posisi terakhir.

SELECT id, customer_id, created_at, total
FROM orders
WHERE tenant_id = 42
  AND (created_at, id) < ('2025-01-10 12:00:00', 987654)
ORDER BY created_at DESC, id DESC
LIMIT 50;

Agar efektif, index harus mengikuti urutan filter dan sort yang dipakai query. Trade-off-nya, paginasi model ini tidak ideal untuk lompat ke halaman arbitrer seperti “halaman 2000”, tetapi untuk API list real-time biasanya jauh lebih efisien.

2. COUNT(*) yang mahal

COUNT(*) bisa murah atau mahal tergantung mesin database, filter, dan apakah index mendukung predicate. Masalah paling umum adalah menghitung total pada tabel besar untuk setiap request.

SELECT COUNT(*)
FROM events
WHERE tenant_id = 42
  AND created_at >= '2025-01-01';

Jika filter tidak ditopang index yang tepat, query ini bisa membaca banyak halaman data hanya untuk menghasilkan satu angka.

Visual yang membantu

COUNT(*) latency by table
sessions    | ###
events      | ##################
audit_logs  | ########################

Alternatifnya:

  • Gunakan counter teragregasi bila kebutuhan tidak harus real-time per baris.
  • Batasi fitur total count pada UI tertentu.
  • Gunakan partisi atau ringkasan harian untuk data time-series besar.
  • Pastikan ada index yang sesuai dengan kolom filter.

Kesalahan umum adalah menambahkan index acak hanya untuk COUNT(*). Yang penting bukan menghitungnya, tetapi apakah filter bisa dipersempit cepat oleh index yang selektif.

3. Index tidak selektif

Index pada kolom seperti status, is_active, atau deleted sering terlihat masuk akal, tetapi nilainya biasanya hanya sedikit variasi. Akibatnya, index tersebut tidak cukup mempersempit pencarian.

SELECT *
FROM orders
WHERE status = 'paid';

Jika sebagian besar data memang paid, index pada status saja sering tidak memberi banyak manfaat. Database mungkin tetap membaca banyak baris.

Visual yang membantu

Distribution: orders.status
paid      | ############################
pending   | ###
failed    | #
refunded  | #

Dari distribusi ini terlihat bahwa status sangat tidak merata. Index tunggal pada status kemungkinan lemah. Biasanya lebih baik menggabungkannya dengan kolom yang lebih selektif dan sesuai pola akses, misalnya (tenant_id, status, created_at) bila query memang selalu difilter tenant dan diurutkan waktu.

4. Index komposit salah urutan

Urutan kolom pada index komposit sangat menentukan. Prinsip umumnya: sesuaikan dengan pola filter, selektivitas, dan sorting yang benar-benar dipakai query.

SELECT id, created_at, total
FROM orders
WHERE tenant_id = 42
  AND status = 'paid'
  AND created_at >= '2025-01-01'
ORDER BY created_at DESC
LIMIT 100;

Misalkan Anda punya dua pilihan index:

idx_a(status, tenant_id, created_at)
idx_b(tenant_id, status, created_at)

Jika aplikasi multi-tenant dan hampir semua query selalu memfilter tenant_id, maka idx_b sering lebih masuk akal. Menaruh status di depan dapat memperlemah pruning bila cardinality status rendah.

Visual audit yang membantu

Composite index usefulness
idx_a(status, tenant_id, created_at)   | ####
idx_b(tenant_id, status, created_at)   | ###############

Visual seperti ini bukan bukti mutlak, tetapi sangat efektif untuk diskusi tim. Ia mendorong review terhadap query nyata, bukan asumsi abstrak tentang index.

Langkah audit praktis yang bisa dijalankan tim backend

Langkah 1: Kumpulkan fingerprint slow query

Normalisasi literal agar query yang sama dengan parameter berbeda dianggap satu kelompok. Contoh:

SELECT * FROM orders WHERE tenant_id = ? AND status = ? ORDER BY created_at DESC LIMIT ?

Untuk tiap fingerprint, catat:

  • count
  • total duration
  • p50/p95/max
  • rows examined
  • rows returned

Lalu tampilkan ranking sederhana:

Top slow query fingerprints
orders_by_status      | total=124s | p95=840ms | examined=2.1M
count_events          | total=88s  | p95=620ms | examined=4.8M
users_offset_page     | total=77s  | p95=910ms | examined=1.7M

Langkah 2: Visualkan distribusi, bukan hanya rata-rata

Rata-rata sering menutupi masalah. Dua query bisa punya rata-rata sama, tetapi satu query memiliki tail latency yang jauh lebih buruk. Karena itu, bucket durasi biasanya lebih informatif.

orders_by_status latency
<10ms      | #######
10-50ms    | ##########
50-100ms   | ####
100-300ms  | ###
300ms+     | ########

Langkah 3: Jalankan EXPLAIN untuk query prioritas

Pilih query dengan biaya total tertinggi atau p95 terburuk. Saat membaca hasilnya, perhatikan pertanyaan berikut:

  • Apakah query memakai index yang diharapkan?
  • Apakah jumlah baris yang dibaca masuk akal untuk hasil yang dikembalikan?
  • Apakah ORDER BY cocok dengan urutan index?
  • Apakah ada filter penting yang tidak tercakup index?

Langkah 4: Audit index yang ada

Buat daftar index per tabel, lalu cocokkan dengan pola query aktual. Tanda bahaya yang umum:

  • Index tunggal pada kolom cardinality rendah.
  • Banyak index mirip dengan prefix yang tumpang tindih.
  • Index komposit tidak sesuai urutan filter/sort.
  • Index tidak pernah dipakai tetapi memperlambat insert/update.

Langkah 5: Pantau pertumbuhan data

Query yang cepat hari ini bisa lambat tiga bulan lagi karena distribusi data berubah. Simpan snapshot harian jumlah baris dan ukuran index, lalu tampilkan ringkasan seperti ini:

Row growth last 7 days
orders      | ########
events      | ####################
audit_logs  | ############################

Jika tabel tumbuh sangat cepat, lakukan audit ulang pada query yang menyentuh tabel tersebut meskipun belum muncul di p95 terburuk.

Contoh laporan teks yang bisa dikirim ke tim

Berikut contoh format laporan yang ringkas tetapi tetap informatif:

SQL Performance Summary - 2026-07-28

1) Top total cost
orders_by_status      | total=124s | count=4200 | p95=840ms
count_events          | total=88s  | count=900  | p95=620ms
users_offset_page     | total=77s  | count=310  | p95=910ms

2) Latency histogram: users_offset_page
<50ms      | #
50-100ms   | ##
100-300ms  | ####
300-800ms  | ########
800ms+     | #######

3) Index audit findings
- idx_users_status: low selectivity, likely weak alone
- idx_orders(status, tenant_id, created_at): order may be suboptimal
- idx_events_created_at: used, but COUNT(*) still scans too wide with tenant filter

4) Growth alerts
orders      | +
events      | +++
audit_logs  | +++++

5) Recommended actions
- Replace OFFSET pagination with keyset pagination on users list
- Review composite index order for orders queries
- Reduce real-time COUNT(*) on events, consider pre-aggregation
- Validate rows examined / rows returned ratio after index changes

Laporan seperti ini cocok untuk email internal, Slack bot, cron job, atau artefak CI setelah menjalankan benchmark query penting.

Kapan visual ringkas lebih berguna daripada dashboard penuh

Dashboard penuh tetap berguna untuk observabilitas jangka panjang, korelasi lintas layanan, dan eksplorasi ad hoc. Namun visual teks sering lebih unggul pada kondisi berikut:

  • Review cepat harian: tim hanya butuh 5-10 sinyal utama.
  • CI/CD: membandingkan sebelum dan sesudah perubahan schema atau query.
  • Code review: hasil audit bisa ditempel langsung di pull request.
  • Insiden performa: terminal output lebih cepat dibagikan daripada membangun panel baru.
  • Tim kecil: belum perlu biaya operasional dashboard tambahan.

Keterbatasannya juga jelas. Visual teks tidak ideal untuk eksplorasi interaktif, korelasi multi-dimensi, atau investigasi historis yang sangat detail. Karena itu, jangan melihatnya sebagai pengganti total dashboard, tetapi sebagai lapisan ringkas untuk pengambilan keputusan cepat.

Kesalahan umum saat membaca histogram dan audit index

Mengandalkan rata-rata

Rata-rata rendah bisa menipu jika bucket latensi tinggi masih besar. Fokus pada distribusi dan p95 untuk endpoint penting.

Menambah index tanpa melihat pola query

Setiap index punya biaya write, storage, dan maintenance. Tambahkan index berdasarkan query prioritas, bukan karena “mungkin berguna”.

Menyamakan cardinality tinggi dengan index pasti bagus

Cardinality membantu, tetapi tetap harus cocok dengan predicate, urutan kolom, dan pola sort. Index bagus di atas kertas bisa buruk untuk query nyata.

Tidak memvalidasi setelah perubahan

Setelah menambah atau mengubah index, ukur ulang:

  • p50/p95
  • rows examined
  • rencana query
  • dampak pada write

Jangan berhenti pada asumsi bahwa index baru otomatis memperbaiki performa.

Panduan implementasi minimal

Jika Anda ingin memulai tanpa tooling kompleks, alur sederhana berikut sudah cukup:

  1. Ekspor slow query log atau event query lambat dari APM/database log.
  2. Normalisasi query menjadi fingerprint.
  3. Hitung distribusi durasi dan total biaya per fingerprint.
  4. Ambil metadata index dan schema dari katalog database.
  5. Jalankan EXPLAIN untuk 5-10 query teratas.
  6. Render histogram/bar teks ke terminal atau file laporan.

Bahasa implementasinya bebas: shell, Python, Go, atau skrip internal lain. Yang penting bukan library visualnya, tetapi konsistensi metrik dan format laporan yang mudah dibaca manusia.

Penutup

Visualisasi query lambat dengan SQL histogram membantu tim backend melihat pola performa tanpa harus selalu membuka dashboard besar. Dengan menggabungkan slow query log, EXPLAIN, distribusi durasi, cardinality, dan audit index, Anda bisa menemukan bottleneck nyata seperti OFFSET besar, COUNT(*) mahal, index tidak selektif, dan urutan index komposit yang salah.

Mulailah dari bentuk paling sederhana: ranking query mahal, histogram durasi, rasio rows examined terhadap rows returned, dan ringkasan audit index. Jika laporan itu dikirim rutin dan dibaca tim, Anda sudah punya fondasi observabilitas SQL yang jauh lebih berguna daripada sekadar mengumpulkan log mentah.