Базы данных

N+1 проблема запросов: почему ORM незаметно убивает производительность

5 августа 2026 · 8 мин чтения

Список из 20 постов на странице открывается за 40 миллисекунд на локальной машине с тестовыми данными — и мгновенно превращается в трёхсекундную загрузку на проде, стоит только базе разрастись. Разработчик открывает профилировщик и видит не один медленный запрос, а сотню одинаковых по форме, но разных по параметру. Это классическая N+1 проблема — один из самых частых источников деградации производительности в приложениях, которые используют ORM. Она коварна именно тем, что совершенно незаметна на маленьких данных и в юнит-тестах, а проявляется только там, где её сложнее всего поймать — на реальной нагрузке.

Что такое N+1 и откуда она берётся

Название описывает механику буквально: один запрос, чтобы получить список из N родительских объектов, и ещё N отдельных запросов, чтобы для каждого из них подтянуть связанные данные. Итого N+1 обращений к базе там, где по сути нужен один или два.

Возникает это почти всегда из-за ленивой загрузки связей (lazy loading) — удобной особенности ORM, из-за которой связанный объект подгружается из базы только в момент, когда к нему реально обращаются в коде, а не заранее. На простом примере с постами и их авторами это выглядит так:

posts = Post.objects.all()  # 1 запрос: получить все посты

for post in posts:
    print(post.author.name)  # ещё 1 запрос на каждый post

Строка Post.objects.all() честно выполняет один SQL-запрос и возвращает список постов. Но у объекта Post нет имени автора внутри — есть только его идентификатор. Как только код обращается к post.author, ORM за кулисами делает отдельный запрос SELECT * FROM users WHERE id = .... Для двадцати постов это будет двадцать отдельных обращений к базе вместо одного джойна — и именно это незаметно происходит внутри цикла, который выглядит как совершенно невинный код.

Почему в разработке этого не видно

N+1 не ломает функциональность — код возвращает корректный результат, просто делает это неэффективно. Именно поэтому проблема так легко проходит код-ревью и тесты: они обычно проверяют, что данные правильные, а не сколько запросов ушло в базу, чтобы их получить.

На локальной базе с десятком тестовых записей двадцать лишних запросов выполняются за миллисекунды — разницу невозможно заметить на глаз.
Сетевая задержка до локальной базы данных близка к нулю, а на проде каждый лишний round-trip к базе — это реальные миллисекунды сетевой задержки, которые умножаются на N.
Проблема обычно прячется не в одном месте, а в шаблонах и сериализаторах — коде, который проходят по остаточному принципу и не всегда держат в голове как источник запросов к базе.
Она растёт вместе с данными: страница, которая была быстрой на 20 записях, становится медленной на 2000 — и это происходит постепенно, без единого момента, когда «что-то сломалось».

Из-за этого N+1 почти никогда не находят по жалобе «тест упал» — её находят по жалобе «страница стала тормозить», уже на проде, и потом долго ищут, в каком месте кода это происходит.

Как найти N+1 в своём коде

Самый надёжный способ — не гадать, а посмотреть на реальное количество запросов. Практически у любого популярного ORM или фреймворка есть встроенный или сторонний инструмент для этого: Django Debug Toolbar показывает список всех SQL-запросов на странице, Rails имеет флаг N+1 query detected в логах через бандл вроде Bullet, у SQLAlchemy можно включить echo=True и просто посчитать строки в логе. Признак почти всегда один и тот же: десятки структурно одинаковых запросов, отличающихся только значением в WHERE id = ....

Хорошая привычка — заводить в тестах или в CI простую проверку: для эндпоинта, который отдаёт список сущностей, зафиксировать ожидаемое количество запросов и падать, если оно вдруг выросло. Это дешевле, чем находить регрессию постфактум по жалобе пользователей на медленную страницу.

Как решать: eager loading вместо ленивой загрузки

Лекарство от N+1 — заранее сказать ORM, какие связи понадобятся, чтобы он подтянул их одним дополнительным запросом или джойном, а не по одному на каждую строку. У разных ORM это называется по-разному, но суть одна и та же:

# Django: один дополнительный запрос вместо N
posts = Post.objects.select_related("author")

# SQLAlchemy: аналогично, через joinedload
posts = session.query(Post).options(joinedload(Post.author))

# Rails: includes вместо ленивой загрузки
posts = Post.includes(:author)

select_related (и его аналоги) строит один SQL-запрос с JOIN, если связь «один к одному» или «многие к одному», как у поста и его автора. Для связей «один ко многим» (например, у поста много комментариев) чаще используют другой механизм — prefetch_related в Django, subqueryload в SQLAlchemy — который делает не JOIN, а второй отдельный запрос со списком всех нужных ID сразу, что избегает дублирования строк родительской таблицы, которое возникло бы при джойне «один ко многим».

N+1 — это не баг конкретной строки кода, а результат того, что ORM спрятал момент обращения к базе внутри обычного доступа к атрибуту объекта. Решение всегда одно: явно сказать, какие данные понадобятся, до того как начался цикл, а не позволять ORM угадывать это по ходу дела.

Когда eager loading — это тоже не бесплатно

Важно не превращать решение в новую крайность. Если жадно подгружать все возможные связи на каждый запрос «на всякий случай», можно получить обратную проблему: тяжёлые запросы с избыточными джойнами там, где связанные данные вообще не используются на этой странице. Разумный подход — подгружать заранее именно то, что реально понадобится в конкретном обработчике или шаблоне, а не превращать select_related в привычку, применяемую бездумно везде.

Итог

N+1 проблема — это плата за удобство ленивой загрузки связей в ORM, а не признак плохого кода сам по себе. Она безобидна на маленьких данных и полностью незаметна, пока не начинает расти количество записей. Единственный надёжный способ её ловить — время от времени реально смотреть, сколько запросов уходит в базу за один обработчик, а не полагаться на то, что «код же работает». Как только связи, которые точно понадобятся, подгружаются заранее одним запросом, а не по одному на каждую строку в цикле, страница, которая раньше линейно замедлялась вместе с ростом данных, снова начинает открываться за миллисекунды.

← Все статьи