1. Yavaş Sorguları Tespit Etme (Profiling)

Optimizasyon ölçümle başlar. Ölçülmeyen sorgu optimize edilemez. İlk adım yavaş sorgu günlüğünü (Slow Query Log) açmak ve yürütme planlarını incelemektir.

Slow Query Log: Eşik değeri belirleyin (örn. long_query_time = 0.5). Eşiği aşan sorguları izleyin.
EXPLAIN / EXPLAIN ANALYZE: Sorgu yürütme maliyetini, taranan satır sayısını (rows) ve kullanılan indeksleri (key) denetleyin.
Sequential Scan Tespiti: Yüksek hacimli tablolarda Seq Scan (Full Table Scan) görüyorsanız indeks eksiktir.

İpucu: EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com'; çıktısındaki actual time değerini temel metrik alın.

2. Doğru İndeksleme Stratejileri

İndeks diskte ek alan tüketir, yazma (INSERT/UPDATE/DELETE) operasyonlarını yavaşlatır. Yalnızca filtreleme ve sıralama yapılan sütunlara indeks uygulanmalıdır.

B-Tree İndeksler

Eşitlik (=) ve aralık (<, >, BETWEEN) sorguları için standart seçimdir.

Composite (Bileşik) İndeksler

Birden fazla sütun içeren sorgularda kullanılır. Sol-öncelik (Leftmost Prefix) kuralı geçerlidir. Seçiciliği (cardinality) en yüksek sütun başa yazılır.

Doğru sıra: CREATE INDEX idx_status_created ON orders (status, created_at);
Sorgu: WHERE status = 'paid' AND created_at > '2025-01-01' indeks kullanır.
Sorgu: WHERE created_at > '2025-01-01' bu indeksi verimli kullanamaz.

Partial (Kısmi) İndeksler

Tablonun sadece belirli bir alt kümesi sorgulanıyorsa indeks boyutunu küçültmek için kullanılır:

CREATE INDEX idx_active_users ON users (email) WHERE is_active = true;

3. Sorgu Seviyesinde Optimizasyon

Kötü yazılmış SQL, doğru indeksi etkisiz kılar. Aşağıdaki anti-pattern kalıplarını temizleyin:

SELECT * Kullanımını Bırakın: Yalnızca gereken sütunları çekin. Bellek ve ağ transfer maliyetini düşürün.
İndeksli Sütunlarda Fonksiyon Çalıştırmayın: WHERE YEAR(created_at) = 2025 indeksi bozar. Bunun yerine WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01' yazın.
Offset Tabanlı Sayfalamadan Kaçının: LIMIT 20 OFFSET 100000 önceki tüm satırları tarar. Cursor/Seek tabanlı sayfalamaya geçin: WHERE id > 100000 LIMIT 20.
N+1 Problemini Çözün: İlişkili verileri döngü içinde tek tek değil, JOIN veya IN (...) ile tek sorguda getirin.

4. Modern Web ve Dijital Ajans Altyapılarında Trendler

Modern dijital ajans işlerinde yüksek trafikli web projeleri için veritabanı optimizasyonu mimari kararlarla desteklenir:

Connection Pooling: Veritabanı bağlantı maliyetini PgBouncer veya native pooler ile minimize edin.
Read/Write Replicas: Okuma yükünü replikalara dağıtın. Master veritabanını sadece yazma işlemlerine ayırın.
In-Memory Caching: Sık okunan, nadir değişen sorgu sonuçlarını Redis/Memcached katmanında saklayın.