Yavaş DB Sorguları Bulma: Query Optimization Kontrol Listesi

Veritabanı (DB) tarafında yaşanan yavaşlamaların büyük bölümü “hangi sorgu yavaş ve neden” sorusuna hızlı cevap verilemediği için uzar. Bu rehberde hedef, uygulamanızı körlemesine kurcalamak yerine ölçüm ile yavaş sorguları bulmak ve optimizasyona net bir sıra vermek. PostgreSQL/MySQL fark etmeksizin aynı yaklaşımı kuracaksınız: yavaş sorgu sinyallerini toplamak, problemli sorguyu izole etmek, yürütme planını okumak ve somut iyileştirmeler uygulamak.

1) Önce tanım: “yavaş sorgu” eşiği nasıl belirlenir?

Yavaş sorgu optimizasyonu, rastgele “hepsini düzeltelim” yaklaşımıyla ilerlemez. İlk adım, yavaş kabul ettiğiniz eşiği netleştirmektir. Çünkü eşik yanlışsa hem yanlış pozitif toplarsınız hem de gerçek sorunu kaçırırsınız.

Uygulama için pratik eşik önerisi

• API endpoint’lerinizin SLA’sı 500 ms ise DB tarafı için hedefi 50–150 ms aralığına çekin.
• Kritik rapor sorguları için hedef süre daha yüksek olabilir (ör. 500 ms–2 sn), fakat “ortalama değil p95/p99” üzerinden karar verin.

Ölçmek için mutlaka şu metrikleri ayırın

• Query duration (sorgu çalışma süresi): DB’nin sorguyu ne kadar sürede tamamladığı
• Lock wait (kilit bekleme): Transaction çakışması
• Rows examined / scanned (tarama sayısı): Index var ama verimsiz tarama olabilir
• Rows returned (dönen satır): Az dönüyor ama çok taranıyorsa problem indeks veya sorgu şeklindedir

2) Yavaş sorguları yakalama: loglar ve performans şeması

Sorguları bulmanın en sağlam yolu, DB’nin ürettiği olayları toplamak ve filtrelemektir. Hosting/VDS ortamında genelde iki yöntem öne çıkar: slow query log (yavaş sorgu logu) ve performans envanteri (pg_stat_statements / performance_schema benzeri).

PostgreSQL: pg_stat_statements + slow query log

1. pg_stat_statements ile “hangi sorgu ne kadar sürdü?” listesini çıkarın.
2. Gerekiyorsa slow query log ile eşik üstü sorguları yazdırın.

Ölçüm hedefi: “En çok toplam süre harcayan sorgular” ve “süre dağılımı en kötü (p95/p99) sorgular”.

MySQL/MariaDB: slow query log + performance_schema

1. slow query log’u açın ve long_query_time eşiğini belirleyin.
2. “dizine rağmen tarama” veya “kilit bekleme” şüphesinde performance_schema raporlarından destek alın.

Net filtreleme kuralları

Yavaş sorgu listesi geldiğinde şu filtreleri uygulayın: - Sadece “en yavaş tekil” sorgulara değil, toplamda en çok süre harcayan sorgulara da bakın. - “Lock wait” süreleri yüksek mi? Yavaş sorgunun nedeni indeks değil kilit olabilir. - Zaman aralığı dar olsun (ör. son 1 saat), sonra genişletin.

Aşağıdaki tablo, hızlı ayrım yapmanıza yardım eder:

3) Problemli sorguyu izole et: uygulama değil, DB davranışı

“Yavaş endpoint” tek başına DB sorununu kanıtlamaz. Önce sorguyu izole edin: - Uygulama loglarında endpoint’in hangi sorguyu tetiklediğini bulun. - Aynı sorgunun farklı parametrelerle (özellikle tarih aralığı, kullanıcı id, sayfa numarası) nasıl davrandığını karşılaştırın. - Mümkünse sorguyu DB’de doğrudan çalıştırın (prod verisini birebir kopyalayamasanız bile benzer veri ölçeği kritik).

Hedef: sorguyu tek başına çalıştırınca da yavaş mı?

• Evet ise optimizasyon konusu DB’dir.
• Hayır ise uygulama katmanı (N+1 sorgu, yanlış bağlantı havuzu ayarı, gereksiz veri çekme) devrededir.

4) Yürütme planını okuyun: EXPLAIN / EXPLAIN ANALYZE

Yavaş sorguyu bulmak kadar, neden yavaş olduğunu anlamak önemlidir. Bu adımda EXPLAIN çıktısı bir “tahmin” değil, DB’nin nasıl düşündüğünü gösteren kanıttır.

Postgres: EXPLAIN ANALYZE (gerçek süre)

Sorguyu üretim koşuluna yakın parametrelerle çalıştırıp şu yaklaşımı izleyin: - Plan adımlarında “Seq Scan” (tam tarama) var mı? - “Nested Loop” ile binlerce satır döngüye giriyor mu? - “Hash Join” / “Merge Join” beklenen mi, yoksa yanlış sıra mı?

MySQL: EXPLAIN + index kullanım sinyalleri

Kontrol listesi: - type değeri “ALL” (tam tablo taraması) mi? - possible_keys var ama key seçilmiyor mu? Bu durumda koşullar indeksle uyuşmuyor demektir. - rows tahmini çok yüksek mi? İstatistik sorunu veya yanlış seçicilik (selectivity) olabilir.

Plan okurken en sık yapılan hata

Sorgu “çalışıyor” diye indeks aramamak. Doğru yaklaşım şudur: - WHERE ve JOIN koşullarındaki kolonlar indeksleniyor mu? - Sıralama (ORDER BY) ve sayfalama (LIMIT/OFFSET) için uygun indeks var mı? - Fonksiyon kullanımı (örn. WHERE DATE(created_at)=...) indeks kullanımını engelliyor mu?

5) İyileştirme için somut müdahaleler: indeks, sorgu şekli, istatistik

Bu bölümde her adım “ne zaman uygulanır” ve “neyi düzeltir” şeklinde netleştirildi.

5.1 İndeks ekleyin ama körlemesine değil

Hedef, indeks ekleyerek taramayı azaltmak ve JOIN/ORDER BY maliyetini düşürmektir.

Net indeks ekleme kriterleri - WHERE koşulunda sık kullanılan kolonlar - JOIN koşulunda kullanılan kolonlar - ORDER BY ile birlikte kullanılan kolonlar - Tekrarlı sorgu desenleri (aynı filtre + aynı sıralama)

Örnek problem desenleri: - WHERE user_id = ? AND created_at BETWEEN ... → (user_id, created_at) şeklinde bileşik indeks aday olabilir. - ORDER BY created_at DESC LIMIT 20 → created_at için uygun yön/indeks düzeni gerekebilir.

5.2 Sorgu yazımını “indeks dostu” yapın

En yaygın 6 hatayı kontrol edin: - WHERE kolonu üzerinde fonksiyon kullanımı (örn. LOWER(email)=..., DATE(created_at)=...) - Tür uyumsuzluğu (örn. string kolona integer filtre) - JOIN koşulunda farklı collation/format - Büyük OFFSET ile sayfalama (LIMIT 10000 OFFSET 9000) - Gereksiz SELECT listesi (tüm kolonları çekip sonra filtrelemek) - N+1 sorgu (uygulama kaynaklı ama DB’yi tetikler)

5.3 İstatistikleri güncelleyin (index doğru olsa da plan yanlış olabilir)

DB istatistikleri eskidiğinde indeks seçimi yanlış olabilir. - PostgreSQL’de vacuum/analyze yaklaşımı - MySQL’de ANALYZE TABLE / istatistik güncelleme

Net kriter: plan değişimi beklediğiniz halde değişmiyorsa, önce istatistikleri kontrol edin.

5.4 Cache katmanı ile DB yükünü dengeleme

Her şeyi indeksle çözmek mümkün değil. Özellikle okuma yoğun senaryolarda: - Uygulama cache’i - Query cache (varsa sürüm uyumluluğu) - Materialized view / precompute raporlar

Ama ilk hedef yine DB’nin yavaş sorgusunu azaltmak olmalıdır. Cache, DB’deki yanlış planı otomatik düzeltmez.

6) Tekrarlanabilir bir teşhis akışı: 20 dakikalık plan

Aşağıdaki akış, ekibin her seferinde aynı şekilde başlamasını sağlar.

1. Son 1–24 saat için yavaş sorgu listesi çıkarın (slow query log veya pg_stat/performance_schema).
2. En yüksek toplam süreyi harcayan ilk 5 sorguyu seçin.
3. Her sorgu için: lock wait, rows examined, rows returned verisini not edin.
4. Sorguyu EXPLAIN (mümkünse EXPLAIN ANALYZE) ile çalıştırın.
5. “Seq Scan / tam tarama”, “yanlış indeks seçimi”, “aşırı nested loop” gibi net sinyalleri işaretleyin.
6. İndeks veya sorgu düzenini bir seferde tek değişken olacak şekilde uygulayın.
7. Yeniden çalıştırıp önceki plan ile farkı doğrulayın.
8. En sonunda süre/CPU/IO metrikleriyle kazanımı belgeleyin.

7) Yalnızca sorguyu değil, DB’nin genel sağlığını da kontrol edin

Bazen “yavaş sorgu” gibi görünen şey aslında kaynak darboğazıdır.

Kontrol edilecek alanlar

• Disk I/O (özellikle yoğun tablo taramalarında)
• CPU doygunluğu
• Bağlantı sayısı (çok fazla eşzamanlı sorgu)
• Transaction süresi (uzun transaction lock biriktirir)
• Otomatik maintenance (vacuum/analyze, index rebuild)

VDS/VPS üzerinde doğru izleme pratiği

NetKıyas kullanıcıları için tipik ortam: VDS/VPS üzerinde DB çalıştırma. Bu durumda aşağıdaki yaklaşım işe yarar: - DB loglarını tek noktada toplayın - Sorgu bazlı raporlarla sunucu bazlı metrikleri zaman hizalayın - Aynı saat diliminde hem “yavaş sorgu” hem “CPU/IO spike” birlikte mi geliyor bakın

Sonuç: Aksiyon planı ile yavaşlığı kalıcı azaltın

İlk hedefiniz “yavaş sorgu var” tespiti değil, hangi sorgu, ne kadar, neden yavaş sorusuna kanıtla cevap vermek olmalı. Bu rehberdeki sırayı uygulayın: yavaş sorgu loglarından liste çıkarın, EXPLAIN ile planı okuyun, indeks/sorgu/istatistik müdahalesini tek tek deneyin ve sonuçları süre/plan farkıyla doğrulayın. Eğer bu akışa dayalı bir çalışma standardı kurarsanız, bir sonraki performans sorunu geldiğinde teşhis süresi dakikaya düşer.