Yavaş Database Sorguları Bulma: Net Query Optimizasyon Rehberi

Veritabanında performans sorunu yaşadığınızda ilk adım doğru sorguyu bulmaktır. “Sunucu yavaş” genellemesi çoğu zaman yanıltır; çoğu performans problemi belirli sorguların (query) hatalı planı, eksik indeksleri veya kilit/yoğunluk (locking) davranışından çıkar. Bu rehberde MySQL ve PostgreSQL tarafında yavaş sorguları bulma sürecini, uygulanabilir ölçüm ve doğrulama adımlarıyla anlatıyoruz. Hedef; hangi sorgunun soruna neden olduğunu netleştirip optimizasyona doğrudan geçmeniz.

1) Yavaş sorguyu “ölçüm” ile bulun: nereden bakılır?

Yavaş sorgu tespiti için iki katman düşünün: (1) veritabanı içinde gerçek çalışan sorgular, (2) uygulama/sunucu loglarında gecikmeye neden olan sorgular.

MySQL: yavaş sorgu logu (slow query log)

MySQL’de yavaş sorgu logunu etkinleştirip hangi threshold’un aşıldığını görürsünüz.

• threshold (ör. 1s veya 500ms): Her ortamda aynı değildir. Önce ölçüm yapıp anlamlı bir eşik seçin.
• sample yaklaşımı: İlk gün 10-20 en yavaş sorguyu listelemek çoğu zaman yeterlidir.
• Log satırlarında genellikle şunlar bulunur: zaman, sorgu metni, istatistikler (sürüm ve ayara bağlı).

En önemli nokta: Logu “sonuçta yavaş olan sorguları” gösterecek şekilde ayarlayın. Örneğin sadece 10 saniyeden uzunları değil, 500ms-1s arası sık tekrar eden sorgular da ciddi toplam yük oluşturabilir.

PostgreSQL: pg_stat_statements ve aktif sorgular

PostgreSQL’de yavaş sorgu tespiti için en pratik araç pg_stat_statements modülüdür.

• Bu modül, çalıştırılan sorguları normalize eder (aynı sorgu kalıbı) ve istatistik tutar.
• Dikkat: Aşırı yüksek sayıda eşsiz sorgu üreten dinamik SQL desenleri (tam parametreli string birleştirme) istatistikleri dağıtır.

Ek olarak: - Aktif kilit/bekleme için pg_stat_activity ve kilit tabloları kullanılır.

Uygulama katmanı: DB çağrısı zamanını uygulama loguna bağlayın

Sorgu optimizasyonu yapmadan önce “o sorgu gerçekten yavaş mı” doğrulaması önemlidir. - Uygulamanızda DB çağrısı süresini loglayın (örn. endpoint + SQL query id + süre). - DB tarafında bulunan yavaş sorgu ile uygulama logundaki yavaş request’i aynı ilişkiyle eşleştirin.

Bu eşleştirme, “DB’de değil uygulamada gecikme var” senaryosunu eleyerek zaman kazandırır.

2) “En yavaş” değil “en pahalı” sorguyu seçin

Bir sistemde aynı sorgu kalıbı çok sayıda kez çalışıyor olabilir. Bu durumda tekil süresi 300ms olan bir query, 1000 kez çağrıldığı için toplamda devasa maliyet oluşturur.

Aşağıdaki öncelik mantığını kullanın:

1. Toplam süre (total time) yüksek sorgular
2. Ortalama süre yüksek sorgular
3. En yüksek sayıda tekrar (calls/executions) yapan sorgular
4. IO/CPU yoğun görünen sorgular

Karar tablosu (hangi sorguyu optimize edeceksiniz?)

3) EXPLAIN ile kök nedeni bulun: indeks mi plan mı?

Yavaş sorgu listesini çıkardıktan sonra bir sonraki adım sorgunun veritabanının nasıl çalıştığını görmektir. Bu noktada EXPLAIN çıktısı “neden yavaş” sorusuna doğrudan yaklaşır.

MySQL: EXPLAIN / EXPLAIN ANALYZE

MySQL’de - EXPLAIN: sorgunun planını görürsünüz. - Bazı sürümlerde EXPLAIN ANALYZE ile gerçek çalıştırma istatistiklerini de görebilirsiniz.

Net bakılacak işaretler: - type = ALL (full table scan) - rows tahmini çok yüksek - key boş veya indeks kullanılmıyor - Extra içinde “Using temporary” / “Using filesort” gibi ifadeler

Kural: “İndeks var ama kullanılmıyor” durumunda çoğu zaman koşul yazımı, fonksiyon kullanımı veya tip dönüşümü (cast) yüzünden indeks atlanır.

PostgreSQL: EXPLAIN (ANALYZE, BUFFERS)

PostgreSQL’de EXPLAIN ile birlikte - ANALYZE: gerçek yürütme ölçümü - BUFFERS: disk/ram okuma davranışı (I/O maliyeti)

Net bakılacak işaretler: - “Seq Scan” (sıralı tarama) yüksek - “Rows Removed by Filter” çok yüksek (filtre çok geç uygulanıyor olabilir) - “Hash Join / Nested Loop” seçimleri ve tahmin sapmaları

Kilit (lock) kaynaklı yavaşlık için EXPLAIN yetmez

Bazı sorgular EXPLAIN’de hızlı plan gibi görünür ama gerçek zamanda kilit bekler. Bu durumda: - MySQL’de SHOW PROCESSLIST / performans şeması ve lock beklemeleri - PostgreSQL’de kilit tabloları ve pg_stat_activity ile bekleyen backend’ler

Bu ayrım kritiktir: İndeks eklemek kilit beklemeyi tek başına çözmeyebilir; transaction tasarımı ve isolation seviyesi de etkiler.

4) İndeks doğrulama: doğru indeks, doğru sırayla

İndeks optimizasyonu en sık yapılan adımdır ama “rastgele indeks eklemek” çoğu zaman kötüleşmeye gider (yazma maliyeti artar, bakım maliyeti yükselir).

İndeks eklemeden önce net kontrol listesi

• WHERE koşulunda kullanılan kolonlar
• JOIN ile bağlanan kolonlar
• ORDER BY ve GROUP BY kolonları
• İlgili kolonlarda kullanılan fonksiyonlar (örn. DATE(created_at) gibi)
• Parametre tipleri (örn. string vs integer) nedeniyle indeksin atlanıp atlanmadığı

Bileşik (composite) indeks: sırayı net seç

Örnek mantık: - WHERE status = ? AND created_at BETWEEN ? AND ? ORDER BY created_at DESC

Bu senaryoda indeks tasarımı genellikle şu mantığa dayanır: - Eşitlik (e.g., status = ?) daha önce gelen kolon olsun - Aralık ve sıralama (e.g., created_at) indeksin içinde doğru sırada yer alsın

Net test yöntemi: indeks ekledikten sonra EXPLAIN’le plan doğrulayın

İndeks ekledikten sonra sadece query süresini manuel ölçmeyin. Şu sırayı uygulayın: 1. İndeks eklendi 2. Aynı sorguyu EXPLAIN ile tekrar çalıştırın 3. key kullanımı (MySQL) veya “Index Scan”/plan değişimi (PostgreSQL) gözleyin 4. Ardından gerçek yük benzeri çalıştırmada süreyi kıyaslayın

5) Yavaş sorgu kaçıyor mu? Parametreleştirme ve yazım hataları

Bazı performans problemleri sorgunun kendisinden değil, sorgu inşa yönteminden kaynaklanır.

Dinamik SQL ve planların çoğalması (plan cache problemi)

• Uygulama her istek için farklı literal’lar gömüyorsa (örn. WHERE user_id = 12345 yerine parametre bağlamamak) optimizasyon zayıflar.
• PostgreSQL’de bu durum bazen plan sayısını artırır; MySQL’de de optimizer davranışını olumsuz etkileyebilir.

Net çözüm: - Parametreli sorgular kullanın. - ORM kullanıyorsanız query planı tekrar kullanımını etkileyen “raw string concat” desenlerini azaltın.

Fonksiyonla kolonu sarmalama (index skipleme)

Örnek desen: - WHERE DATE(created_at) = '2026-08-01'

Bu tür kullanım çoğu zaman indeksin etkin kullanımını bozar. Net yaklaşım: - Aralıkla ifade edin: created_at >= ... AND created_at < ...

Tip dönüşümü (implicit cast)

• Kolon integer iken parametre string olarak geliyorsa bazı DB’ler implicit cast yapar. Net çözüm:
• Uygulama tarafında parametre tiplerini doğrulayın.

6) “Bulma → doğrulama → düzeltme” döngüsünü standardize edin

Performans optimizasyonu tek seferlik bir iş değildir. Süreç oturursa tekrar eden problemleri daha hızlı yakalarsınız.

Önerilen 7 adımlı çalışma planı

1. Son 24-72 saatte yavaş sorgu log/istatistik üzerinden ilk 20 sorguyu çıkarın.
2. “En pahalı” kriteriyle 5 sorguyu önceliklendirin.
3. Her sorgu için EXPLAIN ile planı okuyun.
4. Plan sorununu indeks mi, join stratejisi mi, filtreleme mi yoksa kilit mi olduğuna ayırın.
5. İndeks önerisini net gerekçeyle yazın ve mümkünse yalnızca hedef sorguyu hedefleyen indeksi ekleyin.
6. Ekleme sonrası EXPLAIN’de plan değişimini doğrulayın.
7. Gerçek yük benzeri ölçümle (ör. staging) süreyi ve CPU/IO etkisini raporlayın.

İndeks eklediniz ama hızlanmadıysa ne yapmalısınız?

Bu durumda en yaygın 3 neden vardır: - Filtre koşulu indeks için uygun yazılmamış (fonksiyon/CAST var) - İstatistikler güncel değil (özellikle PostgreSQL’de ANALYZE) - Kilit/transaction tasarımı baskın (lock bekleme)

Önce hangisi olduğuna dair EXPLAIN/istatistik bulgusunu bulun; körlemesine indeks artırmayın.

Sonuç: Yavaş sorguyu net bul, sonra ölçülü şekilde düzelt

Yavaş database query sorununu çözmenin en kısa yolu “tahmin etmek” değil, yavaş sorgu tespiti ile başlayıp EXPLAIN ve istatistiklerle kök nedeni netleştirmektir. Önce ilk 20 sorguyu çıkarın, “en pahalı” olan 5 sorguyu seçin, sonra planı doğrulayarak indeks/transaction kaynaklı ayrımı yapın. Aksiyon önerisi: Bu hafta bir hedef belirleyin—en yavaş 5 sorgudan en az 2’sinde EXPLAIN planını iyileştirmeyi ve süre/IO etkisini ölçmeyi planlayın. Sonuçlar netleştikçe optimizasyonlar daha hızlı ve kontrollü ilerler.