Supabase sorgu optimizasyonu
Supabase sorgularını performans için yeniden yazar.
Prompt Metni
Supabase'deki news tablosundan yalnızca id, title, slug ve published_at alanlarını getir. status = published filtresi uygula. Sonuçları published_at ve id ile kararlı biçimde sırala, sayfa başına 20 kayıt getir ve ikinci sayfa örneğini göster. Uygun PostgreSQL indeksini ve N+1 riskini açıkla.
Prompt Sonucu
İlk sayfa:
const { data, error } = await supabase
.from('news')
.select('id, title, slug, published_at')
.eq('status', 'published')
.order('published_at', { ascending: false })
.order('id', { ascending: false })
.range(0, 19)
İkinci sayfa:
const { data, error } = await supabase
.from('news')
.select('id, title, slug, published_at')
.eq('status', 'published')
.order('published_at', { ascending: false })
.order('id', { ascending: false })
.range(20, 39)
Önerilen kısmi indeks:
CREATE INDEX news_published_order_idx
ON news (published_at DESC, id DESC)
WHERE status = 'published';
id ikinci sıralama anahtarı olarak aynı published_at değerine sahip kayıtların sırasını sabitler. Büyük tablolarda offset tabanlı range yerine son görülen published_at ve id değerlerini kullanan keyset pagination daha verimlidir.
N+1 riski, her haber için yazar veya etiketleri ayrı sorguyla çekildiğinde oluşur. İlişkili alanlar tek select içinde alınmalı veya veriler toplu sorgulanmalıdır.