Что такое проблема N+1 и как её решить

Обзор

Проблема N+1 — одна из самых распространённых проблем производительности в Hibernate. Она возникает при неправильной загрузке связанных сущностей и приводит к линейному росту количества SQL-запросов: 1 запрос на родителя + N запросов на дочерние сущности.

🟢 Junior Level

Что такое проблема N+1

Это ситуация, когда Hibernate выполняет один запрос для получения списка объектов, а затем N дополнительных запросов (по одному на каждый объект) для загрузки связанных данных.

@Entity
public class Order {
    @Id
    private Long id;

    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    private List<OrderItem> items;
}

// Проблема N+1:
List<Order> orders = entityManager.createQuery("SELECT o FROM Order o", Order.class)
    .getResultList();  // 1 запрос: SELECT * FROM orders

for (Order order : orders) {
    order.getItems().size();  // N запросов: SELECT * FROM order_items WHERE order_id = ?
}

// Итого: 1 + N = N+1 запросов!
// Если 100 заказов → 101 запрос к БД

Как распознать

В логах видно множество одинаковых SELECT-запросов
Приложение работает медленно при загрузке коллекций
Количество запросов пропорционально количеству записей

Базовые способы решения

JOIN FETCH — объединить в один запрос
@BatchSize — загрузить пакетами
EntityGraph — динамически указать что загружать

Когда НЕ использовать каждый подход к решению N+1

JOIN FETCH — не использовать при нескольких коллекциях (Cartesian product)
@BatchSize — не использовать когда данные нужны ВСЕГДА (лучше JOIN FETCH)
EntityGraph — не использовать в простых CRUD-операциях (overhead на создание графа)
Subselect — не использовать когда родители загружались по одному (Hibernate fallback к SELECT)

🟡 Middle Level

Детальные решения

1. JOIN FETCH в JPQL

@Query("SELECT DISTINCT o FROM Order o JOIN FETCH o.items")
List<Order> findAllWithItems();

// Генерирует один запрос:
// SELECT DISTINCT o.* FROM orders o
// JOIN order_items oi ON o.id = oi.order_id

Важно использовать DISTINCT — без него Hibernate вернёт дубликаты Order (по одному на каждый OrderItem).

2. @BatchSize

@Entity
public class Order {
    @OneToMany(mappedBy = "order")
    @BatchSize(size = 10)
    private List<OrderItem> items;
}

// Вместо N запросов: N/10 запросов
// Hibernate: SELECT * FROM order_items WHERE order_id IN (?,?,?,?,?,?,?,?,?,?)

3. EntityGraph

@EntityGraph(attributePaths = {"items"})
@Query("SELECT o FROM Order o")
List<Order> findAllWithItems();

// Или программно:
EntityGraph<Order> graph = entityManager.createEntityGraph(Order.class);
graph.addSubgraph("items");

List<Order> orders = entityManager.createQuery("SELECT o FROM Order o", Order.class)
    .setHint("jakarta.persistence.fetchgraph", graph)
    .getResultList();

Сравнение подходов

Подход	Когда использовать	Запросов
JOIN FETCH	Всегда нужны связанные данные	1
@BatchSize	Связанные данные нужны иногда	N/batchSize
EntityGraph	Динамическая загрузка	1
EAGER	Никогда (антипаттерн)	N

Типичные ошибки

// ❌ EAGER загрузка для коллекций
@OneToMany(fetch = FetchType.EAGER)
private List<OrderItem> items;
// Всегда загружает все элементы → проблемы с производительностью

// ❌ Несколько JOIN FETCH → Cartesian Product
@Query("SELECT o FROM Order o JOIN FETCH o.items JOIN FETCH o.payments")
// Если 10 заказов × 5 items × 3 payments = 150 строк!

🔴 Senior Level

Внутренняя реализация

Проблема N+1 возникает из-за того, как Hibernate работает с lazy loading proxy:

Order.getItems() возвращает PersistentCollection proxy
   Proxy — это специальный подкласс, который Hibernate создаёт вместо реального объекта. При обращении к его полям Hibernate перехватывает вызов и загружает данные из БД.
При первом обращении к proxy Hibernate проверяет инициализирована ли коллекция
Если нет — выполняет SELECT для конкретного order_id
Для каждого Order — отдельный SELECT, так как каждый proxy инициализируется индивидуально

Продвинутые стратегии

1. Subselect fetching

@OneToMany(mappedBy = "order")
@Fetch(FetchMode.SUBSELECT)
private List<OrderItem> items;

// Один подзапрос для всех:
// SELECT * FROM order_items WHERE order_id IN (SELECT id FROM orders)

SUBSELECT vs @BatchSize: SUBSELECT выполняет один запрос для ВСЕХ загруженных родителей, а @BatchSize разбивает на группы. SUBSELECT выгоднее когда родителей мало, BatchSize — когда много.

2. Hibernate 6 улучшения

// Hibernate 6.2+ поддерживает отдельный SELECT batching по умолчанию
// Больше не нужен @BatchSize для коллекций
// Но для @ManyToOne всё ещё полезен

3. Обнаружение в production

// p6spy — логирование всех SQL
// datasource-proxy — программный перехват
// Spring Boot Actuator + Hibernate Statistics

@Bean
public DataSource dataSource() {
    return ProxyDataSourceBuilder.create(actualDataSource)
        .logQueryBySlf4j()
        .countQuery()
        .build();
}

Архитектурные рекомендации

✅ LAZY по умолчанию для всех связей
✅ JOIN FETCH когда связанные данные нужны всегда
✅ @BatchSize (10-50) для коллекций
✅ DTO projection для read-only сценариев
✅ Мониторинг SQL-запросов в production
✅ Регулярный review slow query log

❌ EAGER без веской причины
❌ Игнорирование N+1 в code review
❌ Отсутствие мониторинга запросов
❌ Использование сущностей вместо DTO для API

Когда N+1 допустим

В редких случаях N+1 может быть приемлем:

Маленькие данные (< 10 записей)
Связанные данные кэшируются в L2 cache
Используется с @BatchSize с большим размером

🎯 Шпаргалка для интервью

Обязательно знать:

Проблема N+1: 1 запрос на родителей + N запросов на дочерние сущности
Основное решение — JOIN FETCH (один запрос с JOIN)
@BatchSize загружает пакетами: N запросов → N/batchSize
EntityGraph для динамической загрузки связей
EAGER для коллекций — антипаттерн, вызывает N+1
DISTINCT обязателен с JOIN FETCH для устранения дубликатов
Несколько JOIN FETCH → Cartesian product (избегайте)
Мониторинг SQL-запросов в production (p6spy, datasource-proxy)

Частые уточняющие вопросы:

Когда N+1 допустим? Маленькие данные (<10 записей), L2 cache, или с @BatchSize
Почему DISTINCT нужен? JOIN возвращает по одной строке на каждый child, DISTINCT убирает дубликаты root-объектов в памяти
Что лучше — JOIN FETCH или @BatchSize? JOIN FETCH когда данные нужны всегда, @BatchSize когда иногда
Как обнаружить N+1? Включить логирование SQL, считать запросы, использовать p6spy

Красные флаги (НЕ говорить):

«Использую EAGER чтобы избежать N+1» — EAGER сам вызывает N+1
«N+1 не проблема для современных ORM» — проблема есть в любом ORM
«Всегда использую JOIN FETCH для всего» — Cartesian product при нескольких коллекциях
«Не监控рую SQL-запросы» — без мониторинга N+1 незаметен

Связанные темы:

[[2. В чём разница между Lazy и Eager загрузкой]]
[[5. Какие стратегии fetch существуют в Hibernate]]
[[6. Что делает аннотация @BatchSize]]
[[28. Как использовать JOIN FETCH для решения проблемы N+1]]
[[29. Что такое projection в JPA]]