Проблема N+1 запросов: почему база данных не выдерживает нагрузку

Опубликовано: 3 марта 2026

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

Что такое N+1 запросов и почему это плохо?

Представьте, что вы выводите список из ста заказов и для каждого заказа хотите показать имя клиента. Наивный код сначала запрашивает сто заказов одним запросом, а затем в цикле для каждого заказа делает отдельный запрос «дай имя клиента по такому-то id». В итоге вместо одного-двух запросов база получает сто один. При десяти заказах это незаметно, но при десяти тысячах каждый лишний запрос — это время на сетевое соединение, разбор SQL и обращение к диску, и всё это умножается на количество строк.

Почему база данных вообще позволяет так делать — разве это не ошибка?

Сама база данных тут ни в чём не виновата: она честно выполняет каждый запрос, который ей прислали, и делает это быстро. Проблема не в СУБД, а в том, как код общается с базой. База данных отлично умеет объединять данные с помощью JOIN за один проход, но если приложение не просит её об этом, а вместо этого стучится по одному разу за каждой записью, СУБД просто честно выполняет то, что от неё просят — раз за разом.

Почему именно ORM-фреймворки так часто становятся источником N+1?

ORM (объектно-реляционное отображение) — удобная штука: она позволяет работать с базой данных как с обычными объектами языка программирования, не думая о SQL. Но за эту удобство приходится платить прозрачностью: код вида «для каждого заказа получи клиента» выглядит невинно, а на самом деле за каждым обращением к связанному объекту ORM тихо генерирует новый запрос. Проблема настолько распространена, что термин «N+1 selects» встречается в документации практически всех крупных ORM ещё с начала двухтысячных — это один из первых уроков, который проходит любой разработчик, начавший работать с Hibernate, Django ORM, Entity Framework или ActiveRecord.

Как понять, что именно N+1 замедляет базу данных?

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

Как исправить N+1 на уровне кода и запросов?

Универсальный принцип — заранее подгружать связанные данные одним запросом вместо множества мелких. На практике это реализуется разными способами:

использовать JOIN и получать все нужные данные одним SQL-запросом;
применять механизм «жадной загрузки» (eager loading), который есть почти во всех современных ORM — он заранее подтягивает связанные объекты пакетом;
загружать связанные записи одним запросом с условием «id IN (список)» вместо отдельного запроса на каждый id;
использовать паттерн батчинга запросов, когда несколько похожих обращений объединяются в одно перед отправкой в базу.

Выбор конкретного способа зависит от того, насколько тесно связаны данные и как часто они меняются, но идея всегда одна — свести много мелких обращений к базе к одному крупному.

Можно ли решить проблему без глубокого переписывания кода?

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

Как не допустить N+1 в новых проектах?

Лучше предотвращать проблему на этапе проектирования, а не искать её постфактум на живом проекте под нагрузкой. Помогают простые привычки: включать логирование SQL уже на этапе разработки, а не только в продакшене; писать тесты, которые проверяют количество запросов на операцию, а не только корректность результата; и по умолчанию использовать жадную загрузку для связей, которые точно понадобятся на странице. Такой подход экономит время на отладку, когда база данных растёт и нагрузка увеличивается.

Кто помогает следить за производительностью базы данных, если своей команды разработки для этого не хватает?

Не у каждого бизнеса есть выделенный специалист, который постоянно анализирует логи запросов и ищет узкие места. В таких случаях помогает платформа «Клауд АйСи»: облачные базы данных и сопутствующие сервисы включают мониторинг производительности, который показывает аномальный рост количества запросов и помогает вовремя заметить проблему вроде N+1, прежде чем она превратится в жалобы пользователей на медленный сайт.

Частые вопросы

Что означает термин «N+1 запросов»?

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

Можно ли встретить N+1 без использования ORM?

Да, проблема возникает в любом коде, который в цикле делает отдельный запрос к базе для каждого элемента ранее полученного списка, независимо от того, используется ORM или чистый SQL.

Всегда ли JOIN решает проблему N+1?

В большинстве случаев JOIN помогает объединить данные в один запрос, но при очень сложных связях иногда эффективнее использовать пакетную загрузку по списку идентификаторов, а не один большой JOIN.

Влияет ли N+1 на маленькие проекты с небольшим объёмом данных?

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