PostgreSQL İndeksleme ve Sorgu Optimizasyonu

PostgreSQL performans sorunları genellikle veri büyüdükten sonra görünür olur. Küçük tabloda hızlı çalışan sorgu, milyonlarca satırda sequential scan yüzünden API yanıt süresini artırabilir. Bu nedenle indeksleme, sorgu kalıbını ve veri dağılımını anlamadan yapılmamalıdır.

B-Tree indeks

B-Tree varsayılan indeks türüdür ve eşitlik, sıralama ve aralık filtrelerinde çoğu zaman yeterlidir. Kullanıcı e-postası, sipariş numarası veya tarih alanı gibi sorgularda iyi sonuç verir. Ancak her kolona indeks eklemek yazma maliyetini ve disk kullanımını artırır.

Composite ve partial index

Birden fazla kolonla filtrelenen sorgularda kolon sırası önemlidir. Sorgu çoğunlukla customer_id, status ve created_at üzerinden ilerliyorsa composite index buna göre tasarlanmalıdır. Yalnızca aktif kayıtlar sık sorgulanıyorsa partial index daha küçük ve hedefli çözüm sunar.

GIN indeks

JSONB, array ve full-text search senaryolarında GIN indeks kullanılabilir. Fakat yazma maliyetini artırabileceği için gerçekten sorgulanan alanlarda tercih edilmelidir. Arama kalitesi için dil ve sıralama beklentisi ayrıca değerlendirilmelidir.

EXPLAIN ANALYZE

İndeksin işe yarayıp yaramadığını anlamanın yolu EXPLAIN ANALYZE çıktısını okumaktır. Sequential Scan her zaman kötü değildir; küçük tablolarda en hızlı seçenek olabilir. Önemli olan gerçek süre, satır tahmini ve kullanılan planın sorguyla uyumudur.

Sonuç

Doğru indeks, sorgunun niyetini ve veri dağılımını yansıtan indekstir. Ölçmeden indeks eklemek yerine plan okuyarak ilerlemek PostgreSQL performansında daha kalıcı sonuç verir.

Pratik uygulama notu

İndeks eklemeden önce yavaş sorgunun tam halini ve parametre dağılımını görmek gerekir. Development ortamındaki küçük veriyle karar vermek yanıltıcıdır. Production kopyası veya benzer hacimde test verisi üzerinde EXPLAIN ANALYZE almak, değişiklik öncesi ve sonrası süreleri karşılaştırmak daha güvenilir sonuç verir.