Производительность Django Views на больших объёмах

В Django View, который отдаёт тысячи записей, время ответа может расти из-за N+1 запросов, лишних столбцов и обработки всего набора в памяти. На ревью важно не угадывать, какая строка «медленная», а проверить число запросов, план SQL и объём данных. Ниже — разбор для Django 5.2; конкретный выигрыш без замеров обещать нельзя.

Сначала выясните, что именно медленно

Замерьте запрос с реалистичными параметрами и объёмом данных. Зафиксируйте время ответа, количество SQL-запросов, их длительность и число возвращаемых строк. В Django Debug Toolbar удобно смотреть запросы локально; в production используйте безопасное журналирование и метрики приложения, не записывая чувствительные данные.

Разделите задержку на части: база данных, Python-код View, сериализация ответа и передача клиенту. Если база выполняет один запрос долго, оптимизация шаблона может ничего не изменить. Если запросов сотни, проверьте повторяющиеся обращения к связанным объектам.

Рефакторинг производительности начинается не с «переписать на быстрее», а с ответа на вопрос: какая операция повторяется или обрабатывает больше данных, чем нужно?

Что искать на ревью

N+1 при обходе связанных объектов

Типичная ловушка: View загружает список заказов, а шаблон для каждого заказа отдельно обращается к клиенту. Один запрос становится одним запросом на список плюс запросом на каждого клиента. Для связи «один к одному» или «многие к одному» обычно подходит select_related(); для обратных и «многие ко многим» — prefetch_related().

orders = Order.objects.filter(status="open").select_related("customer")

for order in orders:
    print(order.customer.name)

Для набора связанных товаров используйте отдельную предварительную загрузку:

orders = Order.objects.filter(status="open").prefetch_related("items")

Не добавляйте оба метода вслепую. select_related() расширяет SQL-соединение, а prefetch_related() выполняет дополнительные запросы и связывает результаты в Python. Проверьте фактическое число запросов и план выполнения.

Чтение всех полей и строк без необходимости

Если ответу нужны только идентификатор, дата и статус, загрузка всех полей модели увеличивает передачу данных и расход памяти. Для небольшого набора полей можно использовать values() или values_list(). Для вычислений на стороне базы рассмотрите агрегаты и выражения ORM вместо цикла по объектам.

rows = Order.objects.filter(status="open").values(
    "id",
    "created_at",
    "status",
)

Здесь возвращаются словари, а не экземпляры модели. Это удобно для простого ответа, но может потребовать изменить код сериализации и тесты. Сначала проверьте, что View и шаблон не рассчитывают на методы модели.

Один огромный ответ вместо ограниченной выборки

Пагинация ограничивает объём данных на один ответ, но у неё есть цена: стандартный Paginator обычно считает общее количество объектов, а запрос COUNT на большой таблице тоже может быть дорогим. Измеряйте его отдельно. Если интерфейсу не нужно точное общее число страниц, обсудите с продуктовой командой подход с ограниченной выборкой и признаком наличия следующей страницы.

Не загружайте весь QuerySet в список только ради последующего обхода. Когда требуется последовательно обработать большой результат и не держать все объекты одновременно, в Django 5.2 есть iterator(). Он обходит результаты без обычного кеширования QuerySet в памяти; при использовании prefetch_related() укажите размер порции через chunk_size.

for order in Order.objects.filter(status="open").iterator(chunk_size=1000):
    process_order(order)

Это не универсальная замена пагинации для HTTP-ответа: длинная обработка всё ещё может занять время и удерживать запрос открытым. Для тяжёлой фоновой работы обычно нужен отдельный процесс или очередь задач.

Подходы и их цена

Выбирайте приём по профилю: повторяющиеся запросы к связям — повод проверить предварительную загрузку; лишние поля — сузить выборку; слишком большой ответ — ограничить выдачу и измерить стоимость подсчёта. Если узкое место в сложном SQL, сначала изучите план запроса и индексы, а не переносите работу в Python.

Что ломается на границах

• Предварительная загрузка не нужна шаблону. Получите лишние строки и память, если View загружает связанные записи, которые ответ не использует.
• Пагинация не даёт ожидаемого ускорения. Запрос подсчёта может оставаться дорогим; сравните время страницы с временем COUNT.
• Оптимизированный запрос меняет форму данных. После перехода на values() элементы больше не являются экземплярами модели; проверьте сериализатор, шаблон и тесты.
• Замер сделан на пустой базе. Небольшой набор не выявит рост числа запросов и расход памяти. Используйте обезличенные данные сопоставимого масштаба.

Для каждого изменения сравните один и тот же сценарий до и после: одинаковые параметры, объём данных и окружение. Запишите число запросов, время самого медленного SQL, общее время ответа и размер ответа. Если показатели расходятся, не объявляйте победителя по одному числу: ускорение базы может сопровождаться ростом времени сериализации.

QuerySet¹ — ленивое описание запроса ORM: пока результат не нужен, Django обычно не выполняет SQL. Итерация, преобразование в список или обращение к отдельным операциям могут привести к выполнению запроса.

Что делать дальше

Возьмите один медленный View и сохраните его текущие показатели. Затем проверьте повторяющиеся SQL-запросы, поля выборки и размер ответа; внесите одно изменение и повторите замер на сопоставимых данных. После этого добавьте тест, который ловит рост числа запросов для типового набора, и следите в production за временем ответа и долей ошибок. Устройство пагинации и выбор индексов — отдельные темы: здесь важно сначала установить, какая из них действительно ограничивает View.

Источник: официальная документация Django 5.2 по оптимизации доступа к базе данных.