Sorun: Listeleme kodunda gizli sorgu çoğalması
N+1 problemi, bir listeyi almak için yapılan ana sorguya ek olarak her kayıt için ayrı bir sorgu çalışmasıdır. Kod ilk bakışta doğru sonuç üretebilir; sorun özellikle kayıt sayısı arttığında sorgu sayısının ve yanıt süresinin büyümesidir.
Kurgusal PHP örneği:
Burada ilişkisi tembel yükleniyorsa 1 adet gönderi sorgusunun ardından her gönderi için bir kullanıcı sorgusu çalışabilir. 50 gönderi için toplam sorgu sayısı 51'e çıkabilir. Ancak sorgu sayısını yalnızca kaynak koduna bakarak kesinleştirmek mümkün değildir; ORM ayarları ve ilişki tanımları sonucu değiştirebilir.
AI'dan istenecek inceleme ve olası düzeltme
Koda ek olarak modelden ilişki yükleme davranışını, beklenen kayıt sayısını ve sorgu günlüğünü değerlendirmesini istemek daha sağlıklıdır. Örnek inceleme istemi:
Bu örnekte repository metodu, gönderileri alırken gerekli yazar ilişkisini tek bir toplu sorguyla veya ORM'nin uygun eager-loading mekanizmasıyla getirir. Gerçek projede yöntemin adı kullanılan ORM'ye göre değişir. Sadece benzeri bir ifade eklemek, ilişkinin gerçekten doğru yüklendiğini kanıtlamaz; üretilen SQL ve dönen sonuçlar ayrıca kontrol edilmelidir.
AI değerlendirmesinin belirsizliği
AI şu noktaları kesin olarak bilemeyebilir:
Doğrulama adımları
N+1 problemi, bir listeyi almak için yapılan ana sorguya ek olarak her kayıt için ayrı bir sorgu çalışmasıdır. Kod ilk bakışta doğru sonuç üretebilir; sorun özellikle kayıt sayısı arttığında sorgu sayısının ve yanıt süresinin büyümesidir.
Kurgusal PHP örneği:
$posts = $postRepository->findPublished();
foreach ($posts as $post) {
echo $post->title;
echo $post->author->displayName;
}Burada
authorAI'dan istenecek inceleme ve olası düzeltme
Koda ek olarak modelden ilişki yükleme davranışını, beklenen kayıt sayısını ve sorgu günlüğünü değerlendirmesini istemek daha sağlıklıdır. Örnek inceleme istemi:
ORM destekliyorsa ilişkiyi toplu olarak önceden yükleme yaklaşımı şöyle olabilir:Bu PHP ORM kodunda kayıt sayısı arttığında sorgu sayısının nasıl değişeceğini incele. N+1 ihtimalini belirt, varsayımlarını yaz ve sorgu günlüğüyle doğrulanabilecek bir test öner. İlişkiyi gereksiz tüm alanları çekmeden önceden yükleyen bir düzeltme sun.
$posts = $postRepository->findPublishedWithAuthors();
foreach ($posts as $post) {
echo $post->title;
echo $post->author->displayName;
}Bu örnekte repository metodu, gönderileri alırken gerekli yazar ilişkisini tek bir toplu sorguyla veya ORM'nin uygun eager-loading mekanizmasıyla getirir. Gerçek projede yöntemin adı kullanılan ORM'ye göre değişir. Sadece
with('author')AI değerlendirmesinin belirsizliği
AI şu noktaları kesin olarak bilemeyebilir:
- İlişkinin tembel mi yoksa önceden yüklenmiş mi olduğu
- Repository katmanının görünmeyen bir önbellek kullanıp kullanmadığı
- ORM'nin aynı kullanıcıyı tekrar sorgulamak yerine bellekte saklayıp saklamadığı
- Liste sorgusunun gerçekten kaç kayıt döndürdüğü
- Yazar alanının her kayıt için kullanılıp kullanılmadığı
Doğrulama adımları
- Sorgu günlüğünü test ortamında etkinleştirin ve önce 0, 1, 10 ve 100 gönderiyle listeyi çalıştırın.
- Toplam sorgu sayısını ve sorguların kayıt sayısıyla birlikte nasıl değiştiğini kaydedin.
- Düzeltme öncesi ve sonrası aynı veri setiyle karşılaştırma yapın.
- Her gönderinin gerekli yazarının gerçekten döndüğünü, eksik ilişkilerin sessizce yanlış sonuca dönüşmediğini kontrol edin.
- Yanıt süresinin yanı sıra bellek kullanımını da gözlemleyin; tüm ilişkileri sınırsız biçimde önceden yüklemeyin.
- Sorgu sayısını bir testte üst sınırla koruyun; örneğin sayfalı 20 kayıt için kabul edilen sorgu sayısını projenin ORM davranışına göre açıkça belirleyin.