Одна из самых частых тем на собеседованиях Java/backend-разработчиков ⇒ Проблема N+1 в JPA

→ 1 первичный запрос: получение N родительских сущностей.
→ Затем N дополнительных запросов: для каждой из этих N сущностей выполняется отдельный запрос, чтобы загрузить связанные дочерние данные.
→ В итоге выполняется 1 + N запросов к БД, что приводит к снижению производительности и замедлению отклика.

Пример:
Получаем 100 авторов (1 запрос), а затем в цикле вызываем author.getBooks() для каждого (N=100) — в итоге 101 запрос.

⇒ Как решить проблему N+1 в JPA

⇆ Цель — загрузить связанные данные за меньшее количество запросов, желательно за один проход к базе.

1. JPQL/HQL JOIN FETCH (рекомендуется для конкретных связей)
Позволяет явно указать JPA, что ассоциации нужно подгружать через JOIN в запросе.

Пример:

@Query("SELECT a FROM Author a JOIN FETCH a.books")
List<Author> findAllWithBooks();

Плюсы: один эффективный запрос.
Важно: при джойне нескольких коллекций можно получить декартово произведение.

2. Batch Fetching
(@BatchSize или hibernate.default_batch_fetch_size)
Вместо одного запроса на каждого родителя, связанные коллекции загружаются пакетами — по нескольким ID за один запрос.

Пример:

@BatchSize(size = 10)
@OneToMany(...)
private List<Book> books;

Плюсы: уменьшает количество запросов с 1 + N до 1 + (N / batch_size), избегая проблемы декартовых произведений.

3. Entity Graphs
(@EntityGraph — Spring Data JPA / JPA 2.1+)
Позволяет декларативно определить, какие связи нужно подгружать eagerly для конкретного метода репозитория.

Пример:

@EntityGraph(attributePaths = "books")
List<Author> findAll();

Плюсы: гибкая и переиспользуемая стратегия загрузки без явных JPQL JOIN’ов.

Всегда используйте явные стратегии загрузки (такие как JOIN FETCH, @BatchSize или @EntityGraph), чтобы избежать проблемы N+1 и обеспечить эффективное взаимодействие с базой данных.

👉 Java Portal