N+1 query समस्या सबसे सामान्य Django ORM performance समस्या है: एक loop में related objects तक पहुँचना प्रत्येक के लिए एक अलग database query ट्रिगर करता है। select_related और prefetch_related related data को कुशलता से fetch करके इसे हल करते हैं — ये आवश्यक optimization उपकरण हैं।
books = Book.objects.()
book books:
(book.author.name)
प्रत्येक book.author access lazily database को फिर से query करता है। 100 books के साथ, यह 101 queries हैं — एक गंभीर, चालाक performance killer जो अक्सर केवल वास्तविक data volumes के तहत ही सामने आता है।
# ✅ 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 उसी query में related object(s) को fetch करने के लिए एक SQL JOIN करता है। इसे forward ForeignKey और OneToOne relationships के लिए उपयोग करें (एकल related object), जहाँ एक JOIN कुशल है।
# ✅ 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 related objects के लिए एक अलग query चलाता है और उन्हें Python में जोड़ता है। इसे ManyToMany और reverse ForeignKey relationships के लिए उपयोग करें (कई related objects), जहाँ एक JOIN rows को अकुशल रूप से गुणा कर देगा।
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 query समस्या Django applications में सबसे सामान्य और प्रभावशाली performance समस्या है, और select_related/prefetch_related को समझना performant code लिखने के लिए आवश्यक है।
यह समस्या कपटी है क्योंकि वही सुविधाजनक ORM syntax जो related objects तक पहुँचना इतना आसान बनाता है (book.author.name) हर बार चुपचाप एक database query ट्रिगर करता है — जो code कुछ records के साथ ठीक काम करता है, वह वास्तविक data volumes के साथ विनाशकारी रूप से बिगड़ जाता है (100 records → 101 queries), अक्सर केवल production में load के तहत खोजा जाता है।
ये दो उपकरण मानक, आवश्यक समाधान हैं: select_related एक एकल query में forward ForeignKey/OneToOne relationships को fetch करने के लिए एक SQL JOIN का उपयोग करता है, जबकि prefetch_related ManyToMany/reverse-ForeignKey relationships के लिए एक अलग query (Python में जोड़ी गई) का उपयोग करता है जहाँ एक JOIN अकुशल होगा — और यह जानना कि किस relationship type के लिए किसका उपयोग करें मुख्य कौशल है।
इन्हें निपुण करना सैकड़ों queries को एक या दो में बदल देता है, अक्सर page performance में नाटकीय रूप से सुधार करता है।
यह optimization इतना मूलभूत है कि N+1 समस्याओं को पहचानना (अत्यधिक query counts देखने के लिए Django Debug Toolbar जैसे उपकरणों का उपयोग करना) और सही fix लागू करना एक मूल योग्यता है जो कुशल Django code लिखने वाले developers को उनसे अलग करती है जिनकी apps data बढ़ने के साथ धीमी हो जाती हैं।
यह सबसे अक्सर-परीक्षित Django interview विषयों में से भी है, ठीक इसलिए क्योंकि यह व्यावहारिक, performance-महत्वपूर्ण ORM समझ को दर्शाता है।