Что такое N+1 SELECT проблема и как с ней бороться?

Оглавление

  1. Введение
  2. Проблема N+1 SELECT
  3. Структура сущностей User и Order
  4. Генерируемые SQL при LAZY-загрузке (пример N+1 SELECT)
  5. Способы устранения проблемы N+1 SELECT
  6. Частое заблуждение: «FetchType.EAGER решает проблему N+1 SELECT»
  7. Пагинация и N+1 SELECT
  8. Заключение

Введение

Работа с данными в Java-приложениях на основе Spring Data JPA и Hibernate является чрезвычайно удобной благодаря автоматической генерации SQL-запросов и простоте работы с объектами. Однако, вместе с удобством часто приходят и проблемы производительности, самой известной из которых является проблема N+1 SELECT.

Проблема N+1 SELECT возникает незаметно для разработчика и способна существенно снизить производительность даже небольшого приложения. Причина проста: когда мы загружаем список сущностей с лениво загружаемыми (lazy) связанными коллекциями, вместо одного эффективного запроса в базу данных отправляется множество отдельных запросов.

Например, представим приложение, где у нас есть пользователи (User), и у каждого пользователя есть множество заказов (Order). Если мы попытаемся получить список всех пользователей, а затем отдельно обратиться к списку заказов каждого из них, то вместо одного запроса Hibernate сделает 1 запрос на выборку пользователей и дополнительно по одному запросу на каждый список заказов каждого пользователя.

Многие разработчики ошибочно полагают, что проблема N+1 SELECT решается простым переключением загрузки на жадный режим (EAGER). Однако на практике это лишь скрывает проблему, а иногда даже ухудшает ситуацию.

В данной статье мы подробно рассмотрим:

  • В чём именно заключается проблема N+1 SELECT, используя простой и понятный пример (User -> Order).
  • Какие SQL-запросы генерирует Hibernate при ленивой загрузке коллекций по умолчанию.
  • Почему использование FetchType.EAGER не является корректным решением.
  • Какие эффективные механизмы предлагает Hibernate и Spring Data JPA для борьбы с этой проблемой (JOIN FETCH, EntityGraph, @BatchSize, SUBSELECT, DTO-проекции).
  • Как пагинация влияет на проблему N+1 SELECT и как правильно решать подобные ситуации.

Цель публикации – дать понимание того, как диагностировать и эффективно решать проблемы производительности, связанные с загрузкой данных в приложениях на Spring Data JPA и Hibernate.

Проблема N+1 SELECT

При работе с ORM Hibernate можно столкнуться с классической проблемой производительности – N+1 SELECT. Ситуация возникает, когда при загрузке одной сущности, связанной с набором других (например, пользователь и его заказы), Hibernate выполняет сначала 1 основной запрос за родительскими сущностями, а затем N дополнительных запросов – по одному на каждую дочернюю сущность. В итоге, вместо одного сложного запроса ORM делает множество простых, что резко увеличивает нагрузку на базу данных.

Разберем следующий пример: есть сущность User и связанные с ней заказы Order (отношение «один ко многим» – один пользователь имеет много заказов). Если мы попросим через репозиторий JPA загрузить всех пользователей и затем в коде обратимся к их заказам, по умолчанию Hibernate выполнит N+1 запрос: один запрос, чтобы получить список пользователей, и еще по одному запросу на заказы для каждого пользователя:

List<User> users = userRepository.findAll(); 
for (User u : users) {
    System.out.println(u.getOrders().size()); // доступ к ленивой коллекции
}

При ленивой загрузке связей (FetchType.LAZY) Hibernate сперва получит всех пользователей, а затем при первом обращении к коллекции orders каждого пользователя выполнит отдельный SELECT для выборки его заказов. Если пользователей 10, будет 1 (первичный) + 10 (дополнительных) запросов – итого 11. Такое поведение и называется «N+1 SELECT».

Почему это плохо? Каждый лишний запрос – это сетевое взаимодействие с СУБД и потенциально дорогостоящая операция. При большом N (много пользователей, у каждого много связанных записей) время ответа и нагрузка на БД возрастают нелинейно, что может привести к серьезным проблемам производительности.

Основная причина проблемы N+1 SELECT – ленивый характер загрузки связанных коллекций по умолчанию. В JPA отношения @OneToMany и @ManyToMany по умолчанию помечены FetchType.LAZY, что правильно с точки зрения отсечения ненужных данных. Однако ленивость в сочетании со стандартным режимом выборки FetchMode.SELECT означает, что связанные сущности будут запрашиваться отдельными запросами по мере обращения к ним. В итоге, неявно для разработчика, простой на вид код генерирует множество SQL-вызовов.

Пример SQL при N+1 SELECT (User -> Orders). Предположим, в таблице 5 пользователей. Тогда при итерации, показанной выше, Hibernate сгенерирует SQL примерно следующего вида:

-- Первый запрос: получить всех пользователей
SELECT * 
FROM users;

-- Дополнительные запросы для каждой ассоциированной коллекции orders:
SELECT * 
FROM orders 
WHERE user_id = 1;

SELECT * FROM orders WHERE user_id = 2;
... и так для каждого пользователя (user_id = 3,4,5)

Мы видим 1 запрос на пользователей и N=5 запросов на заказы – проблема налицо. Ниже схематично показан поток выполнения запросов в этом случае.

@startuml
title "Проблема N+1 SELECT"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT * FROM users
DB --> App: N пользователей
loop для каждого пользователя (N раз)
    App -> DB: SELECT * FROM orders WHERE user_id = ?
    DB --> App: заказы пользователя
end
@enduml

Диаграмма: при ленивой загрузке Hibernate делает один запрос за пользователями и N запросов за их заказами (N+1 запрос всего).

Структура сущностей User и Order

Чтобы детально разобраться, определим структуру наших сущностей. Предположим, мы имеем следующие JPA-классы (используем Spring Data JPA 3.5.0, Hibernate 6.x, PostgreSQL):

@Entity
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Order> orders;
    // ... getters/setters
}

@Entity
public class Order {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String product;
    private BigDecimal amount;
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;
    // ... getters/setters
}

Здесь у User определена ленивозагружаемая коллекция orders. Атрибут mappedBy = "user" указывает, что сторона владельца связи – в сущности Order (поле user). Каждый Order в свою очередь ссылается на User через связь ManyToOne. По умолчанию у коллекций FetchType.LAZY, поэтому Hibernate не загружает заказы сразу при выборке пользователя – вместо этого он подставит заглушку (прокси), которая инициализируется только при реальном доступе к данным. Именно тогда и происходят дополнительные запросы.

Важно отметить: такое поведение – часть спецификации JPA и удобный механизм, позволяющий не тянуть лишние данные. Однако без правильной оптимизации оно ведет к N+1-проблеме.

Генерируемые SQL при LAZY-загрузке (пример N+1 SELECT)

Теперь продемонстрируем проблему на конкретном сценарии. Допустим, мы хотим получить список всех пользователей вместе с их заказами. Наивная реализация:

List<User> users = userRepository.findAll(); // получаем всех пользователей
for (User user : users) {
    // обращаемся к ленивой коллекции внутри цикла
    List<Order> orders = user.getOrders();
    System.out.println(user.getName() + " имеет " + orders.size() + " заказов.");
}

При запуске такого кода в логах Hibernate (при spring.jpa.show-sql=true) мы увидим примерно следующее:

Hibernate: select u.id, u.name from users u;
Hibernate: select o.id, o.user_id, o.product, o.amount from orders o where o.user_id=1;
Hibernate: select o.id, o.user_id, o.product, o.amount from orders o where o.user_id=2;
Hibernate: select o.id, o.user_id, o.product, o.amount from orders o where o.user_id=3;
... и так далее для каждого пользователя

Первый запрос выбирает всех пользователей (получаем 1…N id пользователей). Далее для каждого пользователя выполняется отдельный запрос SELECT ... FROM orders WHERE user_id = ?. Такая последовательность запросов соответствует описанной проблеме N+1. Чем больше пользователей и чем больше у них заказов, тем сильнее станет просаживаться производительность приложения.

В нашем примере на каждый user.getOrders() Hibernate инициирует SELECT по таблице заказов. Графически это выглядит так же, как на предыдущей диаграмме: сначала один запрос на пользователей, затем цикл запросов на заказы для каждого пользователя.

Отметим, что проблема N+1 может проявляться не только с коллекциями (@OneToMany), но и с ленивыми связями @ManyToOne или @OneToOne, если они идут в коллекции или повторяются в выборке. Основной признак – ORM выполняет каскад из множества схожих запросов там, где можно было бы обойтись одним. Далее мы попробуем разобраться, как решить эту проблему различными способами.

Способы устранения проблемы N+1 SELECT

К счастью, Hibernate и JPA предоставляют несколько подходов для борьбы с N+1 SELECT. К основным относятся:

  • Использование JOIN FETCH в JPQL-запросах.
  • Применение EntityGraph (как через аннотации, так и программно).
  • Аннотация @BatchSize для пакетной выборки.
  • Аннотация @Fetch(FetchMode.SUBSELECT).
  • DTO-проекции через JPQL (выборка нужных данных в одном запросе).

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

JOIN FETCH (загрузка через JOIN)

Суть метода: с помощью ключевого слова JOIN FETCH в JPQL или HQL мы явно заставляем Hibernate подгрузить связанную коллекцию в рамках основного запроса. ORM выполнит один SQL-запрос с объединением таблиц пользователя и заказов, вместо отдельного запроса на каждую коллекцию.

Пример использования JOIN FETCH. Мы можем написать пользовательский запрос или метод репозитория:

// Вариант 1: JPQL через @Query
@Query("SELECT u FROM User u JOIN FETCH u.orders")
List<User> findAllWithOrders();

// Вариант 2: использование Criteria API
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<User> cq = cb.createQuery(User.class);
Root<User> root = cq.from(User.class);
root.fetch("orders", JoinType.LEFT);
List<User> users = em.createQuery(cq).getResultList();

В обоих случаях Hibernate сгенерирует один SQL с JOIN. Например, для варианта с JPQL (и учитывая отношение one-to-many, где не у всех пользователей могут быть заказы) логично использовать левое объединение:

SELECT u.id, u.name, o.id, o.user_id, o.product, o.amount 
FROM users u 
LEFT JOIN orders o ON u.id = o.user_id;

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

Диаграмма потока для этого подхода:

@startuml
title "JOIN FETCH: один запрос"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT u.*, o.* FROM users u LEFT JOIN orders o ON u.id = o.user_id
DB --> App: пользователи с заказами
@enduml

Диаграмма: использование JOIN FETCH приводит к одному объединенному запросу, возвращающему пользователей и их заказы.

Плюсы метода JOIN FETCH:

  • Минимум запросов: одна выборка данных вместо множества. Это радикально снижает накладные расходы на взаимодействие с БД.
  • Простой синтаксис JPQL: легко понять и использовать; поддерживается также в методах Spring Data (аннотация @Query).
  • Данные полностью инициализированы: после выполнения запроса все необходимые сущности находятся в persistence context.

Минусы и ограничения:

  • Дублирование результатов на SQL уровне: при объединении 1:N строка пользователя повторяется для каждой связанной строки заказа. Hibernate скрывает дубликаты на уровне объектов (используя коллекции), но на уровне передачи данных объем может возрасти. Если у пользователя 1000 заказов, JOIN вернет 1000 строк, повторяя данные пользователя.
  • Нельзя напрямую применять с пагинацией: использование JOIN FETCH в JPQL-запросе, комбинированном с LIMIT/OFFSET (пагинацией), приводит к некорректным результатам. Лимит применяется к числу строк (пользователь ? заказы), а не к числу уникальных пользователей, что либо урежет список, либо выдаст повторяющихся пользователей. Hibernate 5 вообще выдавал предупреждение “HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!”, а Hibernate 6 по умолчанию выбрасывает исключение при попытке выполнить пагинацию с fetch join (fail-safe поведение). Мы подробнее разберем это в разделе про пагинацию.
  • Ограничение на один коллекционный fetch join за запрос: JPA спецификация не позволяет в одном JPQL запросе делать JOIN FETCH более чем одной коллекции. Нарушение ведет к декартову произведению и проблемам с резалтсетом. То есть, за один запрос вы можете подтянуть только одну коллекцию. Если нужно подгрузить несколько разных коллекций – придется либо делать несколько запросов, либо использовать другие способы (EntityGraph, подграфы и т.д.).

В целом, JOIN FETCH хорошо подходит, когда вы заранее знаете необходимость подгрузить связь (например, всегда нужно выводить заказы вместе с пользователем) и объем данных умеренный. Это самый прямолинейный способ избежать N+1: мы явно просим базу вернуть все за один раз.

EntityGraph (граф загрузки)

Суть метода: EntityGraph – это механизм JPA, позволяющий задавать, какие связи нужно подгружать, вне зависимости от текста самого запроса. Мы как бы описываем граф необходимых данных, а Hibernate сам решает, как его загрузить (обычно тоже через JOIN или дополнительные SELECT’ы, но оптимизированно).

В Spring Data JPA графы можно задавать аннотациями или программно и применять к методам репозиториев.

Аннотационный подход (NamedEntityGraph): в классе-сущности объявляется именованный граф:

@Entity
@NamedEntityGraph(name = "User.withOrders", 
    attributeNodes = @NamedAttributeNode("orders"))
public class User { ... }

Затем в репозитории можно использовать этот граф:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    @EntityGraph(value = "User.withOrders", type = EntityGraph.EntityGraphType.FETCH)
    List<User> findAll(); 
}

Аннотация @EntityGraph прицепится к выполнению метода findAll() и подскажет Hibernate, что поле orders нужно подтянуть сразу. Тип FETCH означает подгрузить указанную связь, игнорируя ее лази-настройку. (Существует также тип LOAD, который загружает граф только если соответствующая связь используется, но для наших целей подходит FETCH).

Программный подход: можно создавать граф динамически:

EntityGraph<User> graph = entityManager.createEntityGraph(User.class);
graph.addAttributeNodes("orders");
Map<String, Object> props = new HashMap<>();
props.put("javax.persistence.fetchgraph", graph);
List<User> users = entityManager.findAll(User.class, props);

Либо при выполнении JPQL:

TypedQuery<User> q = em.createQuery("SELECT u FROM User u", User.class);
q.setHint("javax.persistence.fetchgraph", graph);
List<User> users = q.getResultList();

Под капотом оба подхода делают одно и то же – Hibernate видит подсказку графа и включает связанные сущности в запрос. В случае коллекции one-to-many, Hibernate обычно выполнит JOIN (аналогично JOIN FETCH). Если бы граф включал вложенные атрибуты, он мог бы сделать дополнительные SELECT или несколько JOIN’ов. В нашем простом случае (только orders) – это эквивалент JOIN FETCH.

Примечание: EntityGraph обычно реализует загрузку через JOIN, но Hibernate может также использовать отдельные SELECT-запросы в зависимости от структуры графа и оптимизации.

SQL, генерируемый с EntityGraph: будет таким же, как мы приводили для JOIN FETCH:

SELECT u.id, u.name, o.* 
FROM users u 
LEFT JOIN orders o ON u.id = o.user_id;

Поток запросов – один запрос к базе:

@startuml
title "EntityGraph: один запрос"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT u.*, o.* FROM users u LEFT JOIN orders o ON u.id = o.user_id (EntityGraph)
DB --> App: пользователи с заказами
@enduml

Диаграмма: применение EntityGraph приводит к одному SQL-запросу с JOIN, аналогично JOIN FETCH.

Плюсы EntityGraph:

  • Отделение запроса от плана загрузки: вы можете использовать стандартные методы репозитория (например, findAll(), findById() или даже кастомные JPQL) и применить к ним граф, не переписывая запросы. Это удобно для переиспользования – один и тот же метод можно вызвать то с графом, то без, в зависимости от контекста.
  • Явное описание требований к данным: в коде видно, какие именно связи мы хотим получить. Можно описывать сразу целые подграфы (через @NamedSubgraph) для вложенных ассоциаций.
  • Поддерживает несколько связей сразу: в одном графе можно указать несколько @NamedAttributeNode, и Hibernate попытается их все загрузить оптимально. (Ограничения: множественные коллекции тоже могут дать декартово произведение, но Hibernate может разбить на несколько запросов или собрать через join + subselect).

Минусы EntityGraph:

  • Требует настройки и понимания под капотом: новичкам может показаться магическим. На самом деле, это надстройка, упрощающая жизнь, но важно понимать, что граф не меняет тип запросов – например, он не может обойти ограничение с пагинацией и join (если под капотом всё равно делается JOIN). Он также не гарантирует один запрос – Hibernate сам может решить подгрузить некоторые отношения отдельными запросами, особенно если граф сложный.
  • Специфично для JPA 2.1+ и привязано к провайдеру: Hibernate поддерживает, EclipseLink тоже, но в чистом JPA без поддержки провайдера графы бесполезны. В Spring Data JPA проблем нет – он полностью умеет работать с EntityGraph.

Примечание: Несмотря на то, что EntityGraph позволяет указать несколько атрибутов для одновременной загрузки, необходимо учитывать ограничение спецификации JPA, согласно которому использование нескольких JOIN FETCH с коллекциями может привести к формированию декартова произведения (Cartesian Product) и непредсказуемым результатам. Поэтому рекомендуется внимательно управлять количеством коллекций, загружаемых одновременно.

Вывод: EntityGraph – мощный способ бороться с N+1, особенно в большом приложении, где хочется централизованно описать стратегии загрузки. Например, можно объявить граф "User.withOrders" и всегда использовать его в тех сервисах, где нужны заказы. Это избавит от необходимости всюду писать JOIN FETCH в запросах. По сути, EntityGraph – декларативный вариант JOIN FETCH. Best practice – использовать его, когда нужно подгружать сразу несколько связанных коллекций или когда хочется управлять загрузкой без переписывания существующих репозиториев. Согласно рекомендациям, fetch join или entity graph – лучшие способы исправить N+1 в большинстве случаев.

@BatchSize (пакетная выборка)

Суть метода: аннотация @BatchSize (Hibernate-специфичная) позволяет загружать связанные сущности пакетами фиксированного размера, когда они запрашиваются лениво. Это не устраняет полностью дополнительные запросы, но уменьшает их количество с N до N/батч_размер примерно. Hibernate будет не по одной сущности запрашивать дочерние, а группировать несколько ключей и выбирать пачками.

Как работает @BatchSize: Например, если поставить @BatchSize(size = 5) над коллекцией orders в User:

@OneToMany(mappedBy="user", fetch = LAZY)
@BatchSize(size = 5)
private List<Order> orders;

Это означает: когда Hibernate понадобится инициализировать ленивую коллекцию orders у какого-то пользователя, он одновременно подтянет заказы для еще до 4 других пользователей, чьи коллекции неинициализированы и находятся в текущем persistence context. Таким образом, если у нас уже загружено 20 пользователей и мы начинаем итерировать по их заказам, Hibernate выполнит запросы примерно по 5 пользователей за раз.

Пример SQL с BatchSize=5: Для 20 пользователей это будет: 1 запрос на пользователей, затем 4 дополнительных запроса на заказы:

SELECT * FROM users;
SELECT * FROM orders WHERE user_id IN (?,?,?,?,?);  -- для пользователей 1-5
SELECT * FROM orders WHERE user_id IN (?,?,?,?,?);  -- для пользователей 6-10
SELECT * FROM orders WHERE user_id IN (?,?,?,?,?);  -- для пользователей 11-15
SELECT * FROM orders WHERE user_id IN (?,?,?,?,?);  -- для пользователей 16-20

Таким образом, вместо 20 запросов на заказы получили 4. Общий счет: 1 + 4 = 5 запросов вместо 21 – значительное улучшение, хотя и не один запрос. Количество запросов примерно равно ceil(N / batchSize) для каждой коллекции.

Диаграмма процесса при BatchSize:

@startuml
title "@BatchSize: пакетная загрузка"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT * FROM users
DB --> App: N пользователей
loop группами по batch_size пользователей
    App -> DB: SELECT * FROM orders WHERE user_id IN ( ... )
    DB --> App: заказы для этой группы
end
@enduml

Диаграмма: при BatchSize Hibernate выполняет несколько запросов на заказы, каждый захватывает группу пользователей.

Преимущества @BatchSize:

  • Очень простое применение: достаточно поставить аннотацию на сущность или коллекцию – не нужно переписывать запросы, репозитории. Этот механизм прозрачно работает во всех местах, где участвует ленивый loading.
  • Снижает нагрузку по сравнению с чистым N+1: вместо большого числа мелких запросов выполняется несколько более крупных. Это существенно улучшает производительность, особенно при ровном доступе к коллекциям.
  • Работает даже с пагинацией: в отличие от JOIN FETCH, batch-size не конфликтует с использованием LIMIT/OFFSET, так как основной запрос на пользователей остается прежним (с лимитом), а уже потом батчи запросов выбирают дочерние записи. Таким образом, можно безопасно странично выбирать пользователей, а их связи подтягивать через batch.

Недостатки @BatchSize:

  • Все еще несколько запросов: хотя запросов меньше, чем N+1, они остаются множественными. Если сеть между приложением и БД медленная, один большой запрос мог бы быть эффективнее, чем несколько маленьких.
  • Подбор оптимального размера батча: размер в 5 в нашем примере – произвольный. Если поставить слишком большой, можно снова перегрузить БД (слишком большое выражение IN (…)). Слишком маленький – мало толку. Часто рекомендуют 16-32 в зависимости от средней выборки. Нужно профилировать под свою нагрузку.
  • IN (?,?,?) имеет ограничения: например, Oracle не позволяет более 1000 элементов в списке внутри IN. В PostgreSQL таких ограничений нет, но очень длинные списки тоже могут тормозить. Так что если выбрать огромный batchSize, можно получить неэффективный запрос. Обычно разумные значения – десятки, максимум сотни.
  • Требует Hibernate: @BatchSize – специфичная аннотация Hibernate (в JPA стандарте ее нет). Если в будущем сменится провайдер, этот код станет неработающим или бесполезным. (EclipseLink имеет аналог @BatchFetch). Впрочем, Spring Boot по умолчанию использует Hibernate, так что это нечасто проблема.

Вывод: @BatchSize – компромиссный способ. Он не устраняет проблему на 100%, но значительно ее смягчает. Хорошо подходит, когда:

  1. нельзя или неудобно переписать все запросы с JOIN FETCH,
  2. данные все равно потребляются лениво (например, шаблоны DAO используются в разных комбинациях),
  3. важна поддержка пагинации.

Hibernate позволяет ставить @BatchSize не только на коллекции, но и на классы сущностей, чтобы батчился загрузка прокси-объектов ManyToOne. Например, если несколько заказов ссылаются на одного пользователя (lazy ManyToOne), и вы начинаете их итерировать, Hibernate тоже может выполнить один запрос для нескольких пользователей сразу. В общем, batch fetching – универсальный инструмент оптимизации запросов при ленивой загрузке.

@Fetch(FetchMode.SUBSELECT) (подзапрос для коллекций)

Суть метода: аннотация @Fetch(FetchMode.SUBSELECT) – еще одна Hibernate-специфичная настройка для @OneToMany и @ManyToMany. Она говорит ORM: при необходимости загрузить ленивую коллекцию для нескольких родительских объектов, выполни один запрос с подзапросом, охватывающим всех этих родителей. То есть Hibernate сначала выбирает родителей, а потом вторым запросом получает все дочерние записи для всего набора родителей сразу (а не по частям или по одной).

Отличие от batch: batch делает несколько запросов с IN (…), а subselect пытается сделать один запрос с WHERE ... IN (subselect).

Пример использования: пометим коллекцию заказов аннотацией:

@OneToMany(mappedBy="user", fetch = LAZY)
@Fetch(FetchMode.SUBSELECT)
private List<Order> orders;

Теперь, если мы получили список пользователей (например, 10 штук) и затем начнем обходить их заказы, Hibernate сделает следующее:

  • Первый запрос: SELECT ... FROM users (как обычно).
  • Второй запрос (при обращении к любой orders): SELECT ... FROM orders WHERE user_id IN ( ... ), где в скобках – список всех id пользователей, загруженных первым запросом. Причем этот запрос выполнится один раз и сразу загрузит коллекции для всех пользователей этого списка.

Можно представить, что Hibernate делает примерно так:

SELECT * 
FROM users  -- получили пользователей (например, IDs: 1,2,3,...,10)

SELECT * 
FROM orders 
WHERE user_id IN (1,2,3,...,10);

И далее разберет результаты, разложив заказы по соответствующим User. На самом деле, реализация Subselect Fetch в Hibernate чуть изощреннее – он может подставить весь исходный SQL первого запроса как подзапрос. То есть второй запрос может быть таким:

SELECT o.* 
FROM orders o 
WHERE o.user_id IN ( 
    SELECT u.id FROM users u  -- тот самый первоначальный запрос
    -- возможно, здесь же будут условия, сортировка и лимиты первого запроса (кроме offset/limit, см. ниже)
);

Примечание: при использовании Pageable, Hibernate не всегда полностью включает исходные условия (особенно OFFSET и LIMIT), что вызывает проблемы.

В любом случае, на практике мы получаем 2 SQL-запроса вместо N+1 (если коллекция одна). На диаграмме:

@startuml
title "FetchMode.SUBSELECT: два запроса"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT * FROM users
DB --> App: N пользователей
App -> DB: SELECT * FROM orders WHERE user_id IN (SELECT id FROM users)
DB --> App: все заказы для пользователей
@enduml

Диаграмма: FetchMode.SUBSELECT сначала выбирает пользователей, затем одним запросом берет все связанные заказы.

Плюсы FetchMode.SUBSELECT:

  • Минимизирует число запросов (до 2): при одной коллекции фактически заменяет N запросов одним. Для нескольких ленивых коллекций у одной сущности – до 1 запроса на каждую коллекцию для всего набора родителей. Пример: если у User есть коллекции orders и, скажем, phones, то будет 3 запроса: users, orders для всех users, phones для всех users.
  • Удобство декларативности: поставил аннотацию – и по умолчанию все выборки этой коллекции оптимизированы. Не надо помнить про JOIN FETCH в каждом конкретном запросе.
  • Данные грузятся лениво, но эффективно: т.е. пока не обратимся – запросов нет, но как обратились – сразу всё нужное забрали. Это часто соответствует бизнес-требованиям (меньше тратить ресурсов, пока не понадобилось).

Минусы FetchMode.SUBSELECT:

  • Может загрузить лишние данные: если у нас список из 100 пользователей, а мы, например, обратились к заказам только у первого – Hibernate все равно подтянет заказы для всех 100 пользователей (т.к. не знает, к кому мы обратимся). Получается, могли не потребоваться, а мы их выбрали – лишняя нагрузка по памяти и сети.
  • Не применяется к одиночным связям (ManyToOne, OneToOne): FetchMode.SUBSELECT работает только для коллекций. Для ManyToOne можно применять BatchSize, а сабселекта нет.
  • Важно: несовместимость с пагинацией (offset/limit). Если первый запрос за родителями использует LIMIT/OFFSET (например, мы достаем страницу пользователей), Hibernate не включает условие пагинации во второй подзапрос. Это баг/особенность Hibernate: второй запрос выберет все дочерние объекты для всех родителей, даже тех, что были отфильтрованы пагинацией. В результате можно загрузить гигантский объем данных: например, запросили 10 пользователей из миллиона (с limit 10), а второй запрос вытащил заказы для всех миллиона пользователей! Это, очевидно, плохо. Поэтому использовать FetchMode.SUBSELECT вместе с пагинацией нельзя – нужно либо отключать subselect на время, либо применять другие подходы (об этом далее).

Вывод: FetchMode.SUBSELECT – мощное средство устранения N+1 при ленивой загрузке коллекций. Его часто называют золотой серединой между JOIN FETCH и BATCH: он делает минимально возможное число запросов (2) без дублирования строк, как при join. В Hibernate документации отмечено, что subselect fetch эффективно и безопасно применять, когда ожидается, что коллекции все равно будут использованы (например, при отображении данных). Однако осторожно с пагинацией: в таких сценариях subselect может сыграть злую шутку, вытащив лишние данные.

Практический пример, когда @Fetch(SUBSELECT) отлично подходит – отображение списка сущностей с небольшими связанными коллекциями в веб-приложении без постраничного режима. Например, вы показываете отчет по 50 пользователям и их 2-3 последних заказа. Первый запрос выбрал 50 пользователей, второй одним махом взял ~150 заказов – оптимально. Но если бы включили постраничный вывод, лучше отключить subselect или ограничить размер выборки, иначе на последней странице всё равно загрузятся заказы со всех страниц.

DTO-проекции через JPQL (выборка в класс-проекцию)

Суть метода: все предыдущие способы имели дело с полноценными сущностями и управлением контекстом persistence. Иногда же можно поступить иначе: просто выполнить чистый запрос (JPQL или SQL) нужной формы, чтобы сразу получить требуемые данные, минуя повторные обращения. То есть забрать не сущности, а необходимые поля (или даже сложную агрегированную структуру) в DTO (Data Transfer Object). Поскольку запрос пишется вручную, мы можем оптимально соединить таблицы или использовать агрегаты, тем самым избежать N+1.

Пример DTO-проекции: для нашей задачи «пользователи и их заказы» можно написать JPQL с явным JOIN, но не делать fetch, а вернуть данные в DTO:

public class UserOrderInfo {
    private String userName;
    private String product;
    private BigDecimal amount;
    // конструктор
    public UserOrderInfo(String userName, String product, BigDecimal amount) {
        this.userName = userName;
        this.product = product;
        this.amount = amount;
    }
    // getters ...
}

// В репозитории:
@Query("SELECT new com.example.dto.UserOrderInfo(u.name, o.product, o.amount) " +
       "FROM User u JOIN u.orders o")
List<UserOrderInfo> fetchUserOrderInfo();

Этот запрос вернет список объектов UserOrderInfo, каждый из которых содержит имя пользователя и информацию о одном заказе. На уровне SQL Hibernate выполнит единственный JOIN (аналогичный JOIN FETCH). Например:

SELECT u.name, o.product, o.amount
FROM users u 
JOIN orders o ON u.id = o.user_id;

Каждая строка результата будет соответствовать паре (пользователь – заказ). В нашем DTO эти пары хранятся построчно. Если нам нужно сгруппировать заказы по пользователям, мы можем сделать это уже на уровне Java-кода, сгруппировав список UserOrderInfo по полю userName. Либо можно использовать более сложный JPQL (например, коллекционные проекции, если поддерживаются, или агрегатные функции).

Другой вариант – использовать Spring Data Projection интерфейсы: определив интерфейс с нужными геттерами (включая вложенный список), Spring может частично сам составить оптимальный запрос. Однако для коллекций это не всегда гладко – зачастую Spring Data все равно сделает N+1 при сборке коллекции в проекции. Поэтому безопаснее либо отдавать плоские проекции, либо использовать явный DTO конструктор.

Диаграмма запросов для DTO-проекции:

@startuml
title "DTO-проекция: один запрос"
actor "Приложение" as App
database "PostgreSQL" as DB
App -> DB: SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id
DB --> App: данные пользователей и заказов (DTO)
@enduml

Диаграмма: при проекции JPQL выполняется один запрос, возвращающий необходимые поля пользователей и заказов.

Плюсы DTO-проекций:

  • Максимальная гибкость и эффективность: вы пишете произвольный SQL/JPQL под задачу. Можно выбирать только нужные колонки, использовать WHERE условия, JOIN нескольких таблиц, агрегаты (COUNT, SUM и т.д.). ORM не вмешивается в план запросов – вы контролируете все, следовательно, легко избегаете лишних запросов.
  • Отсутствие сущностей – отсутствие проблем lazy-loading: возвращаются простые объекты, за ними нет persistence context. Не случится N+1, потому что вы вообще не оперируете ленивыми коллекциями – вы уже получили все, что хотели, напрямую запросом.
  • Производительность: как правило, такой подход наиболее быстрый для операций чтения, т.к. убирает оверхед ORM по управлению сущностями. Это особенно хорошо для отчетов, экспортов, отображения списков, где не планируется модификация данных.

Минусы DTO-проекций:

  • Только для чтения (как правило): полученные DTO не привязаны к Hibernate Session, их нельзя прозрачно обновить в базу. Если нужно редактировать – придется либо самому писать UPDATE запрос, либо загружать сущности. Поэтому этот метод годится в основном для read-only сценариев (отображение в UI, генерация отчетов).
  • Требует писать SQL/JPQL вручную: теряется часть «магии» Spring Data JPA. Например, нужно самому поддерживать запрос, следить за соответствием полям DTO. С ростом проекта много ручных запросов – потенциальное место ошибок. Однако, с появлением Criteria API, QueryDSL и т.п., это смягчается – можно генерировать типобезопасно запросы.
  • Не работает с кэшем первого уровня: так как мы обходим Session, данные могут не учитываться если что-то уже загружено или поменяно в рамках текущей транзакции. Но в типичном случае это не проблема (мы либо выполняем такие запросы в отдельной транзакции на чтение, либо они не пересекаются с изменениями).

Вывод: Проекции на основе DTO – отличный способ устранить N+1 в случаях, когда вам не нужны полностью управляемые сущности. Рекомендуется перестать позволять Hibernate генерировать SQL для сложных чтений, а писать свои запросы. В контексте N+1 это означает: вместо того, чтобы загружать 100 пользователей и потом лениво тянуть их 1000 заказов, напишите один запрос, который сразу вернет нужную комбинацию данных.

Использовать этот метод стоит для специализированных выборок: например, отчеты, отображение на дашборде агрегированных данных, экспорт списков, где не требуется дальнейшее взаимодействие с БД через сессионные объекты. В типичном веб-приложении часто 80% запросов на чтение могут быть покрыты JPQL/SQL проекциями, а остальные 20% – это загрузка агрегата с множеством связей (где можно применить JOIN FETCH/граф).

Частое заблуждение: «FetchType.EAGER решает проблему N+1 SELECT»

Одним из распространенных заблуждений среди разработчиков является мнение, что использование жадной загрузки (FetchType.EAGER) автоматически избавляет от проблемы N+1 SELECT. Давайте разберёмся, почему это мнение ошибочно.

Почему возникает заблуждение?

Когда мы устанавливаем загрузку EAGER, JPA сразу же загружает связанные сущности вместе с родительскими объектами. Например:

@OneToMany(fetch = FetchType.EAGER, mappedBy = "user")
private List<Order> orders;

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

Что происходит на самом деле?

Дело в том, что при жадной загрузке коллекций (@OneToMany, @ManyToMany) Hibernate по умолчанию не выполняет один запрос с JOIN, а использует подход с дополнительными SELECT-запросами.

Рассмотрим пример:

List<User> users = userRepository.findAll(); // FetchType.EAGER на orders

В результате Hibernate отправляет в базу следующие SQL-запросы:

-- Запрос на всех пользователей
SELECT * FROM users;

-- И дальше множество отдельных запросов для каждого пользователя
SELECT * FROM orders WHERE user_id = 1;
SELECT * FROM orders WHERE user_id = 2;
SELECT * FROM orders WHERE user_id = 3;
-- и так далее для каждого пользователя

Таким образом, мы получаем классическую проблему N+1, но теперь она спрятана за кажущейся простотой EAGER-загрузки.

Почему это плохо?

  • Неконтролируемость: Запросы выполняются всегда, даже когда данные не нужны.
  • Падение производительности: Количество запросов резко возрастает с увеличением данных.
  • Проблемы с памятью: Жадная загрузка всегда загружает связанные объекты, что приводит к дополнительной нагрузке на память и сеть.
  • Проблемы с пагинацией и множественными коллекциями: Декартово произведение (Cartesian Product) и исключения из-за большого объёма данных.

Что делать?

Правильный подход заключается в использовании ленивой загрузки (FetchType.LAZY) с явным контролем через подходы, описанные выше (JOIN FETCH, EntityGraph, @BatchSize и другие).

Например:

@OneToMany(fetch = FetchType.LAZY, mappedBy = "user")
private List<Order> orders;

// И в репозитории:
@Query("SELECT u FROM User u JOIN FETCH u.orders")
List<User> findAllWithOrders();

Это позволяет явно контролировать загрузку и избежать множества лишних запросов.

Вывод

Использование FetchType.EAGER не является корректным способом решения проблемы N+1 SELECT. Вместо решения проблемы оно лишь делает её менее очевидной и более сложной для диагностики.

Правильный подход — ленивое поведение по умолчанию и явный контроль загрузки через проверенные механизмы JPA и Hibernate.

Пагинация и N+1 SELECT

Отдельно нужно обсудить влияние постраничной выборки (pagination) на проблему N+1 и ее решения. Часто данные отображают на странице пагинированно – например, по 20 записей. Возникает вопрос: что если у нас включена пагинация, и при этом мы хотим избежать N+1?

Главная сложность – метод с пагинацией (findAll(Pageable) в Spring Data или Query.setMaxResults/ setFirstResult в Hibernate) обычно выполняет два запроса: один – за конкретной страницей данных, второй – за общим количеством записей (count). Когда мы начинаем комбинировать это с JOIN FETCH, появляются проблемы:

  • JOIN FETCH + Pageable = ??: Если в JPQL запросе используется fetch join коллекции, Hibernate не может корректно применить лимит. Причина в том, что SQL-результат содержит дубликаты строк при join, и ограничение строк (LIMIT) обрезает результат посередине групп связанных записей. Это приводит к потере некоторых родительских сущностей или к неполному набору детей. Например, хотим 10 пользователей с их заказами, а у 1-го пользователя было 5 заказов – простой LIMIT 10 вернет 6 пользователей (1-й + 5 заказов как 6 строк). Чтобы избежать этого, Hibernate 5.x переводил постраничный запрос с fetch join в два шага в памяти (что малоэффективно), а Hibernate 6.x – по умолчанию вообще бросает исключение “fail on pagination over collection fetch”. Таким образом, нельзя просто написать SELECT u FROM User u JOIN FETCH u.orders и обернуть в PageRequest – это либо не сработает, либо даст неверный результат.
  • Почему Hibernate не делает автоматом правильно? Теоретически, можно было бы сначала получить IDs нужных 10 пользователей, а затем сделать второй запрос с JOIN по ним – тогда limit корректно применяется к родителям. Hibernate 6 частично умеет это: появилась экспериментальная поддержка такой оптимизации (SQL-level pagination). В Spring Data JPA 3.0+ при использовании Hibernate 6 можно попробовать написать метод с @EntityGraph и Pageable – Hibernate может выполнить подзапрос по id. Но это ограничено и пока ненадежно. В общем случае, приходится решать самим.

Примечание: начиная с Hibernate 6.1 появилась встроенная поддержка limit-fetch с подзапросом, но она работает только в простых случаях. Для сложных случаев все равно лучше делать два отдельных запроса вручную.

Способы избежать N+1 при пагинации:

  • Двухэтапная загрузка (recommended): вручную реализовать то, что Hibernate не делает. Сначала выполнить запрос только по родительским сущностям (без fetch, просто получить страницу IDs), затем вторым запросом загрузить связанные данные. Например, используем Spring Data:
    1. Page<User> page = userRepo.findAll(pageRequest); – получаем 20 пользователей.
    2. Затем отдельно загружаем их заказы: userRepo.findAllWithOrdersByIdIn(page.getContent().stream().map(User::getId)) – тут внутри можно сделать JOIN FETCH по ограниченному списку ID. Либо на уровне EntityManager сделать SELECT u FROM User u JOIN FETCH u.orders WHERE u.id IN :ids. В результате имеем пользователей с инициализированными коллекциями. Этот подход рекомендован экспертами и фактически реализует контролируемое решение проблемы: 2 запроса вместо N+1. В примере Vlad Mihalcea для PostgreSQL как раз показывается: сначала выбираются ID постов с пагинацией, потом одним запросом извлекаются посты с комментариями по этим ID.
  • Использовать BatchSize вместо fetch join для пагинированных данных: т.е. позволить первой странице пользователей загрузиться как обычно (с LIMIT), а затем при обращении к их связям Hibernate выполнит батч-запросы. Так мы избежим взрыва запросов: например, на 20 пользователей с batchSize=5 будет 4 запросика – не идеально, но лучше, чем 20. Это вполне жизнеспособно, хотя и не так эффективно, как один join, но зато не конфликтует с пагинацией.
  • Использовать оконные функции или подзапросы для одной строчкой получения данных: если писать нативный SQL, можно воспользоваться возможностями СУБД. Например, в PostgreSQL можно получить пагинированный список пользователей, а потом джойнить с заказами, используя подзапрос. Один из вариантов: SELECT u.*, o.* FROM (SELECT * FROM users ORDER BY name LIMIT 20 OFFSET 40) u LEFT JOIN orders o ON u.id = o.user_id; Здесь вложенный суб-SELECT обеспечивает ограничение 20 пользователей, а join уже подтягивает заказы только для них. Такой запрос можно оформить как native query и спроецировать в DTO или даже в объекты (но нужно аккуратно мэппить, чтобы дубликаты не сбили). Однако подобные вещи плохо переносимы между СУБД и сложны для динамических фильтров.
  • Альтернативная пагинация (keyset pagination): ещё подход – избегать offset/limit и делать пагинацию по какому-то маркеру (например, ID или дате). Тогда можно использовать JOIN FETCH, так как, например, условие WHERE user.id > :lastId не искажает результат, а просто выбирает нужный диапазон. Но это подходит не всегда и требует немалых усилий.

Итог по пагинации: Самый надёжный подход – двухэтапный: отдельно выбрать идентификаторы нужной страницы, затем отдельным запросом получить связанные данные. Можно завернуть это в сервисный метод, чтобы скрыть от вызывающего кода. Spring Data пока не делает этого автоматически (по крайней мере, до версии 3.0.x), поэтому приходится реализовать вручную. BatchSize и субселект в целом работают с пагинацией, но у сабселекта, как мы упоминали, есть риск вытянуть лишнее, а у batch просто будет несколько запросов.

Если же очень хочется уложиться в один запрос – придется писать его самостоятельно с использованием SQL-средств (подзапрос как показано выше, или common table expression). Но это выходит за рамки возможностей JPA и превращается в ручную оптимизацию.

Таким образом, при пагинации стоит избегать fetch join для коллекций и пользоваться либо BatchSize/Subselect, либо ручной дозагрузкой связанных данных. В официальной документации Hibernate прямо указывается, что fetch join не совместим с limit/offset из-за возможных дубликатов. А Vlad Mihalcea рекомендует: «не смешивайте JPQL с JOIN FETCH и Pagination – вместо этого используйте SQL-уровень пагинации (два запроса или Hibernate 6 фичу)».

Заключение

Проблема N+1 SELECT – частый «подводный камень» при использовании Hibernate с ленивой загрузкой. Она способна незаметно деградировать производительность приложения, поэтому важно проактивно её устранять. Мы рассмотрели пять основных подходов. Сведем их в таблицу:

МетодЧисло запросовОсобенностиКогда применять
JOIN FETCH1 (на каждую связь)Использует JOIN, данные загружаются жадно в одном запросе. Возможны дубликаты строк на SQL уровне. Не работает с пагинацией для коллекций.Когда нужно сразу получить связанные данные, объем умеренный, нет пагинации. Простой и эффективный способ для большинства случаев.
EntityGraph1 (по сути тоже JOIN)Декларативное указание связей для подгрузки. Эквивалентно JOIN FETCH, но можно применять к методам репозиториев без переписывания запросов.Если хотите отделить описание загрузки от запроса. Удобно при множественных связях и повторном использовании. Не решает проблему пагинации.
@BatchSize~ 1 + ceil(N/batchSize)Загружает ленивые коллекции пачками. Несколько запросов с IN(). Совместим с пагинацией.Если N может быть большим, а один JOIN слишком тяжелый. Хорош при потоковой обработке или pagination. Требует настройки оптимального размера.
@Fetch(SUBSELECT)2 (при одной коллекции)Загружает все коллекции для группы родителей одним запросом через подзапрос. Очень эффективно (минимум запросов). Но: не включается LIMIT/OFFSET в подзапрос – не использовать с пагинацией!Отлично для отчётов, экранов без пагинации, где надо лениво но эффективно подгрузить коллекции. Дает минимум запросов без дубликатов.
DTO-проекция (JPQL)1 (произвольный запрос)Ручной выбор нужных данных. Требует писать JPQL/SQL. Возвращает не управляемые сущности, а данные.В сценариях “только чтение”, когда нужна максимальная производительность. Например, для сложных списков, агрегированных данных. Полностью устраняет N+1, но неудобно для изменений.

Как видно, универсального решения нет – выбор подхода зависит от контекста:

  • Для простых случаев (небольшие данные, отсутствие сложной пагинации) – используйте JOIN FETCH или EntityGraph. Это сразу избавляет от N+1, код минимально меняется. Например, при отображении деталей пользователя с заказами – явно делать JOIN FETCH заказов.
  • Если у вас большие наборы данных или активная пагинация, присмотритесь к BatchSize. Он позволит безопасно получать страницы без лавины запросов. Комбинируйте его с EntityGraph: например, странично выбрали пользователей, а потом если обращаетесь к связям – batch сделает несколько групповых SELECT’ов.
  • FetchMode.SUBSELECT отлично подходит, когда нужно ленивое поведение, но без накладных расходов – например, генерация PDF отчета со списком всех сущностей и их дочерних коллекций. Вы получите 2-3 запроса вместо сотен. Но не забудьте отключить, если включаете разбиение на страницы (или используйте другой метод для страниц).
  • DTO/проекции – выбор архитектурный. Некоторые проекты вообще стараются изолировать слой ORM и работают с DTO всегда – тогда N+1 не возникает в принципе, т.к. вы всегда сами пишете запросы. В рамках Spring Data можно постепенно вводить проекции для самых нагруженных операций чтения.

Рекомендации:

  1. Мониторинг: первым делом обнаружить N+1 помогает логирование запросов (Hibernate show_sql + format_sql + BasicBinder TRACE для параметров) или профилирование на уровне БД. Если видите шаблон повторяющихся запросов – это сигнал применить один из подходов выше.
  2. Начните с Fetch Join / EntityGraph: это наиболее простое исправление. Добавили – проверили лог: теперь один запрос вместо многих. Если это сломало пагинацию или привело к другим проблемам – тогда уже думать об альтернативах.
  3. Используйте BatchSize глобально для коллекций, которые часто лениво загружаются: это страховка. Например, @BatchSize(size=20) на всех @OneToMany в важных сущностях. Даже если забудете где-то JOIN FETCH, ущерб будет не так велик.
  4. Combining strategies: допускается сочетать: например, можно и EntityGraph на один уровень, и BatchSize на другой, или BatchSize с DTO и т.п. Hibernate довольно гибок. Только не сочетайте в одном запросе fetch join и пагинацию – об этом мы уже подробно сказали.
  5. Проверяйте SQL руками: после внесения оптимизации посмотрите на лог запросов. Убедитесь, что действительно стало лучше (меньше запросов, нет лишних и т.д.). Например, при @BatchSize запросы будут другие – с IN. При JOIN FETCH – один большой join. Оценивайте, что быстрее в вашей ситуации (зависит от данных и индексов).

В заключение отметим, что с выходом Hibernate 6 некоторые аспекты улучшились: появился встроенный механизм разбиения страницы с fetch join (Hibernate сам делает подзапрос по ID), правда работает он пока только для простых случаев и требует Spring 6+. Поэтому в актуальной версии Spring Data JPA 3.5 выбор подхода все еще остается за разработчиком. Грамотно применяя рассмотренные методы, можно обеспечить и корректность, и эффективность данных операций. Помните: N+1 SELECT – это не баг Hibernate, а следствие ленивой загрузки, и устранить его – задача архитектора приложения. Благодаря JPA/Hibernate у нас есть для этого все инструменты. Пользуйтесь ими и пусть ваша база не страдает от лишних запросов!

Loading