N+1 sorgu problemi en yaygın Django ORM performans sorunudur: bir döngü içinde ilişkili nesnelere erişmek, her biri için ayrı bir veritabanı sorgusu tetikler. select_related ve prefetch_related bunu ilişkili verileri verimli bir şekilde getirerek çözer — bunlar temel optimizasyon araçlarıdır.
books = Book.objects.()
book books:
(book.author.name)
Her book.author erişimi veritabanını tembel bir şekilde yeniden sorgular. 100 kitap ile bu 101 sorgu demektir — ciddi, gizli bir performans katili ve genellikle yalnızca gerçek veri hacimleri altında ortaya çıkar.
# ✅ ONE query with a JOIN
books = Book.objects.select_related("author").all()
for book in books:
print(book.author.name) # NO extra queries — author was JOINed in
# 100 books → 1 query total
select_related ilişkili nesne(leri) aynı sorgu içinde getirmek için SQL JOIN gerçekleştirir. İleri ForeignKey ve OneToOne ilişkileri (tek ilişkili nesne) için kullanın; burada JOIN verimlidir.
# ✅ TWO queries total (not N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
for book in author.books.all(): # NO extra queries — books were prefetched
print(book.title)
# query 1: all authors; query 2: all their books → Django joins them in Python
prefetch_related ilişkili nesneler için ayrı bir sorgu çalıştırır ve bunları Python'da birleştirir. ManyToMany ve ters ForeignKey ilişkileri (çoklu ilişkili nesneler) için kullanın; burada JOIN satırları verimsiz bir şekilde çoğaltır.
select_related → ForeignKey, OneToOne (forward, single object) → SQL JOIN, 1 query
prefetch_related → ManyToMany, reverse ForeignKey (many objects) → 2 queries, joined in Python
You can combine and chain them, and span relationships:
Book.objects.select_related("author").prefetch_related("tags")
Book.objects.select_related("author__publisher") # multi-level
✓ Django Debug Toolbar — shows the query count per page (spot N+1 visually)
✓ django-silk, or logging queries (connection.queries) to count them
→ If a page runs hundreds of similar queries, you likely have an N+1.
N+1 sorgu problemi Django uygulamalarındaki tek en yaygın ve etkili performans sorunudur ve select_related/prefetch_related anlamak verimli kod yazmak için gereklidir.
Sorun sinsi olduğu için, ilişkili nesnelere erişimi bu kadar kolay yapan kullanışlı ORM sözdizimi (book.author.name) her seferinde sessizce bir veritabanı sorgusu tetikler — az sayıda kayıtla iyi çalışan kod, gerçek veri hacimleri ile (100 kayıt → 101 sorgu) felaket düzeyinde bozulur, genellikle sadece üretimde yük altında keşfedilir.
Bu iki araç standart, gerekli çözümdür: select_related ileri ForeignKey/OneToOne ilişkilerini tek bir sorgu içinde getirmek için SQL JOIN kullanır, prefetch_related ise ManyToMany/ters-ForeignKey ilişkileri için ayrı bir sorgu (Python'da birleştirilmiş) kullanır; burada JOIN verimsiz olur — ve hangi ilişki türü için hangisini kullanacağınızı bilmek anahtar beceridir.
Bunları ustaca kullanmak yüzlerce sorguyu bire veya ikiye dönüştürür, genellikle sayfa performansını dramatik bir şekilde iyileştirir.
Bu optimizasyon o kadar temel bir hale gelmiştir ki, N+1 problemlerini tanımak (Django Debug Toolbar gibi araçlar kullanarak aşırı sorgu sayısını tespit etmek) ve doğru düzeltmeyi uygulamak, verimli Django kodu yazan geliştiricileri uygulamaları veri arttıkça yavaşlayan geliştiricilerden ayıran temel bir yetkinliktir.
Aynı zamanda en sık test edilen Django mülakat konuları arasındadır, tam da bunun pratik, performans açısından kritik ORM anlayışını yansıtması nedeniyle.