PostgreSQL performansı: sorgu planı, indeks ve bağlantı havuzu

Kimler için?

PostgreSQL kullanan mobil backend geliştiricileri.

Başlamadan önce

Temsili staging verisi, sorgu metni ve ölçülebilir API gecikmesi.

1. API gecikmesini parçalara ayırın

Bir endpoint’in yavaş olması yalnızca SQL’e bağlı değildir. Bağlantı bekleme, dış servis, JSON üretimi ve N+1 sorgu da süre ekler. Önce istek süresini aşamalara ayırın. Liste başına yüz kayıt getirip her kayıt için ayrı sorgu çalıştırmak, tek sorgudaki küçük bir indeks iyileştirmesinden daha büyük sorun olabilir. Kişisel veriyi loglamak yerine süre ve sorgu imzası tutun.

2. EXPLAIN ile planı okuyun

EXPLAIN planın hangi yolu seçtiğini gösterir. EXPLAIN ANALYZE sorguyu gerçekten çalıştırır; özellikle yazma sorgularında üretimde düşünmeden kullanmayın. Temsili veriyle staging’de gerçek süreyi ve satır tahminini karşılaştırın. Küçük tabloda sequential scan makul olabilir; her scan otomatik hata değildir.

-- Kendi staging tablonuza uyarlayın. ANALYZE sorguyu çalıştırır.
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at FROM notes
WHERE project_id = 42
ORDER BY created_at DESC, id DESC LIMIT 20;

3. İndeksi sorgunun şekline göre deneyin

Bir proje içindeki son kayıtları okuyan sorgu için filtre ve sıralama birlikte önemlidir. Aşağıdaki indeks yalnızca örnekteki sorgu ve şemaya yönelik bir adaydır; tüm uygulamalar için reçete değildir. İndeks disk ve yazma maliyeti ekler. Sonucu önceki planla kıyaslayın, gereksiz indeksleri de değerlendirin.

CREATE INDEX notes_project_recent_idx
ON notes (project_id, created_at DESC, id DESC);

4. Sayfalama ve ilişkileri sınırlandırın

Kararlı bir cursor sıralaması kullanın; aynı tarihli kayıtlar için id gibi bir sonlandırıcı ekleyin. İstemci limitine sunucu üst sınırı uygulayın. İlişkili veriyi toplu sorguyla almak veya seçilmiş alanları döndürmek N+1 yükünü azaltabilir. Gereksiz büyük JSON payload’ı ağ ve mobil bellek yükünü de büyütür.

5. Bağlantı havuzunu bütçelendirin

Her API sürecinin ve worker’ın ayrı havuzu olabilir. Süreç sayısı ile havuz boyutunu çarpmadan toplam bağlantıyı planlamak hatalıdır. Veritabanında yönetim ve bakım için pay bırakın. Havuz bekleme süresi, açık transaction ve uzun sorgu izlenmelidir; daha fazla bağlantı her zaman daha fazla throughput üretmez.

6. Değişikliği tekrar ölçün

Aynı veri seti ve istek karışımıyla önce/sonra testi yapın. p95, hata, veritabanı CPU/RAM ve yazma süresini kaydedin. Yeni indeksin kurulması büyük tabloda kilit veya iş yükü etkisi oluşturabilir; uygulama yöntemi ve bakım penceresi planlanmalıdır. Başarıyı sadece tek sorgunun en iyi süresiyle değil, normal iş akışıyla değerlendirin.