Проблема N+1 запросов — это наиболее частая проблема производительности Django ORM: доступ к связанным объектам в цикле вызывает отдельный запрос к базе данных для каждого из них. select_related и prefetch_related решают эту проблему путём эффективной выборки связанных данных — это необходимые инструменты оптимизации.
books = Book.objects.()
book books:
(book.author.name)
Каждый доступ к book.author лениво запрашивает базу данных заново. С 100 книгами это 101 запрос — серьёзная и незаметная проблема производительности, которая часто проявляется только при больших объёмах реальных данных.
# ✅ 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 выполняет SQL JOIN для выборки связанного объекта в том же запросе. Используйте его для прямых связей ForeignKey и OneToOne (один связанный объект), где 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 выполняет отдельный запрос для связанных объектов и объединяет их в Python. Используйте его для связей ManyToMany и обратных ForeignKey (несколько связанных объектов), где JOIN неэффективно увеличивает количество строк.
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 запросов — это единственная наиболее частая и влиятельная проблема производительности в приложениях Django, и понимание select_related/prefetch_related необходимо для написания производительного кода.
Проблема коварна, потому что удобный синтаксис ORM, который делает доступ к связанным объектам столь простым (book.author.name), молча вызывает запрос к базе данных каждый раз — код, который хорошо работает с несколькими записями, деградирует катастрофически при реальных объёмах данных (100 записей → 101 запрос), часто обнаруживаясь только в production под нагрузкой.
Эти два инструмента — стандартное, необходимое решение: select_related использует SQL JOIN для выборки прямых связей ForeignKey/OneToOne в одном запросе, а prefetch_related использует отдельный запрос (объединённый в Python) для связей ManyToMany/обратных ForeignKey, где JOIN был бы неэффективен — и умение выбрать подходящий инструмент для каждого типа связи — это ключевой навык.
Освоение этих инструментов превращает сотни запросов в один или два, часто значительно улучшая производительность страницы.
Эта оптимизация столь фундаментальна, что умение распознавать проблемы N+1 (с помощью таких инструментов, как Django Debug Toolbar, для выявления чрезмерного количества запросов) и применять правильное исправление — это базовая компетенция, которая отличает разработчиков, пишущих эффективный код на Django, от тех, чьи приложения замедляются с ростом данных.
Это также одна из наиболее часто проверяемых тем в интервью по Django, именно потому, что она отражает практическое, критичное для производительности понимание ORM.