Какие стратегии fetch существуют в Hibernate

В экосистеме JPA/Hibernate существует два принципиально разных уровня управления выборкой связанных данных, которые часто путают на собеседованиях:

🟢 Junior Level

Фундаментальное разделение: «Когда» против «Как»

JPA FetchType (Отвечает на вопрос «КОГДА загружать?»):
- Стандартный параметр аннотаций JPA (@OneToMany, @ManyToOne и др.).
- LAZY — загрузить отложенно при первом обращении к полю/коллекции.
- EAGER — загрузить немедленно вместе с родительской сущностью.
Hibernate FetchMode (Отвечает на вопрос «КАК (каким SQL) загружать?»):
- Специфичная для Hibernate аннотация @Fetch(FetchMode.xxx).
- Определяет структуру генерируемых SQL-запросов: через отдельный SELECT, через объединение таблиц JOIN или через подзапрос SUBSELECT.

JPA FetchType:
LAZY  ──> Загрузить потом при обращении.
EAGER ──> Загрузить сразу при чтении родителя.

Hibernate FetchMode:
SELECT    ──> Выполнить отдельный вторичный SELECT WHERE id = ?
JOIN      ──> Выполнить один запрос с конструкцией LEFT/INNER JOIN
SUBSELECT ──> Выполнить один вторичный запрос WHERE id IN (SELECT id FROM ...)

Основные стратегии Hibernate `FetchMode`

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

    // 1. SELECT (поведение по умолчанию для LAZY)
    // При обращении к коллекции генерируется отдельный SQL-запрос для каждого заказа
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    @Fetch(FetchMode.SELECT)
    private List<OrderItem> itemsSelect;

    // 2. JOIN
    // При вызове find() генерируется один SQL-запрос с LEFT OUTER JOIN
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    @Fetch(FetchMode.JOIN)
    private List<OrderItem> itemsJoin;

    // 3. SUBSELECT
    // При первом обращении подгружает коллекции для всех ранее выбранных заказов одним запросом
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    @Fetch(FetchMode.SUBSELECT)
    private List<OrderItem> itemsSubselect;
}

🟡 Middle Level

Детальный разбор стратегий `FetchMode`

1. `FetchMode.SELECT`

Как работает: При обращении к неинициализированному прокси или коллекции Hibernate выполняет отдельный параметризованный запрос:
```
SELECT * FROM order_items WHERE order_id = ?;
```
Плюсы: Минимальный начальный запрос, простота кэширования в L1/L2.
Минусы: Главный источник проблемы N+1, если родительские сущности загружаются списком.

2. `FetchMode.JOIN`

Как работает: Hibernate объединяет таблицы через LEFT OUTER JOIN в момент загрузки родителя:
```
SELECT o.*, i.* FROM orders o 
LEFT OUTER JOIN order_items i ON o.id = i.order_id 
WHERE o.id = ?;
```
Критический нюанс: Аннотация @Fetch(FetchMode.JOIN) полностью подавляет и игнорирует FetchType.LAZY! Даже если вы указали fetch = FetchType.LAZY, при наличии @Fetch(FetchMode.JOIN) связанные данные будут загружены сразу же.
Ограничение: Работает только при прямой выборке сущности по первичному ключу (entityManager.find()). При выполнении JPQL-запросов аннотация игнорируется!

3. `FetchMode.SUBSELECT`

Как работает: Доступен только для коллекций. Hibernate запоминает исходный JPQL/SQL-запрос, которым были загружены родительские сущности, и при первом обращении к коллекции любого из родителей выполняет ровно один подзапрос для всей пачки:
```
-- Исходный запрос:
SELECT * FROM orders WHERE status = 'COMPLETED';
  
-- Запрос за коллекциями (SUBSELECT):
SELECT * FROM order_items 
WHERE order_id IN (SELECT id FROM orders WHERE status = 'COMPLETED');
```
Плюсы: Решает проблему N+1 без декартова произведения (Cartesian Product), так как данные родителей и детей возвращаются раздельными результирующими наборами (ResultSet).
Минусы: Если исходный запрос был тяжелым, повторное вычисление подзапроса может нагрузить процессор СУБД.

🔴 Senior Level

Почему `@Fetch(FetchMode.JOIN)` игнорируется в JPQL-запросах

Главная ловушка для сеньор-разработчика:

@Entity
public class Order {
    @ManyToOne(fetch = FetchType.LAZY)
    @Fetch(FetchMode.JOIN)
    private User user;
}

// Запрос в репозитории:
List<Order> orders = entityManager.createQuery("SELECT o FROM Order o", Order.class)
        .getResultList();

Что произойдет? Разработчик ожидает, что Hibernate сделает JOIN с таблицей users. Но Hibernate выполнит N+1 запросов!

Причина поведения ядра Hibernate:

Спецификация JPA требует, чтобы JPQL-запрос выполнялся строго в соответствии с текстом самого запроса. Если в запросе написано SELECT o FROM Order o, Hibernate обязан выбрать только данные таблицы orders.
Аннотации @Fetch относятся к статическим метаданным маппинга и управляют поведением метода entityManager.find() или загрузкой ленивых прокси по внешним ключам.
JPQL-парсер имеет наивысший приоритет. Он полностью игнорирует аннотацию @Fetch(FetchMode.JOIN) над полями сущности!
Чтобы заставить JPQL сделать объединение, разработчик обязан написать явную динамическую директиву: SELECT o FROM Order o JOIN FETCH o.user.

Классификация динамических стратегий выборки

Опытный архитектор различает статические стратегии (аннотации в Entity) и динамические (выбор стратегии под конкретный сценарий):

                                  СТРАТЕГИИ ВЫБОРКИ (FETCH)
                                              │
                    ┌─────────────────────────┴─────────────────────────┐
                    ▼                                                   ▼
         СТАТИЧЕСКИЕ (Entity-level)                          ДИНАМИЧЕСКИЕ (Query-level)
   (Задаются жестко в коде модели;                     (Выбираются под конкретный сценарий;
    не поддаются локальной перенастройке)               максимальная гибкость и производительность)
         │                                                   │
         ├── FetchType (LAZY / EAGER)                        ├── JPQL JOIN FETCH
         ├── @Fetch (SELECT / JOIN / SUBSELECT)              ├── JPA EntityGraph (fetchgraph/loadgraph)
         └── @BatchSize (Пакетный IN-fetch)                  └── DTO Projections (SELECT new Dto)

Сравнение механизмов динамического Fetching

Механизм	Уровень объявления	Число SQL	Обработка пагинации	Cartesian Product
`JOIN FETCH`	JPQL / HQL / Criteria	1	❌ Опасно (выгрузка в память)	❌ Возникает при нескольких коллекциях
`@EntityGraph`	Репозиторий / Запрос	1	❌ Опасно (выгрузка в память)	❌ Возникает при нескольких коллекциях
`@BatchSize`	Entity / Глобально `application.yml`	$1 + \lceil N / \text{size} \rceil$	✅ Безопасно (LIMIT/OFFSET в БД)	✅ Отсутствует (раздельные запросы)
`FetchMode.SUBSELECT`	Коллекция в Entity	2	⚠️ Зависит от диалекта SQL	✅ Отсутствует (раздельные запросы)

4 Tricky Questions

1. Почему комбинация `FetchType.LAZY` и `@Fetch(FetchMode.JOIN)` считается взаимоисключающей, и что выберет Hibernate?

Ответ: Hibernate выберет немедленную загрузку через JOIN, проигнорировав FetchType.LAZY:

Семантика FetchMode.JOIN предписывает: «При загрузке родительской записи немедленно соединить ее с целевой таблицей через внешний JOIN».
Поскольку строка таблицы-партнера уже извлечена из результирующего набора JDBC ResultSet в первом же запросе, создавать пустой прокси-объект и откладывать чтение на потом не имеет никакого смысла.
Таким образом, добавление @Fetch(FetchMode.JOIN) фактически превращает ленивую связь в жадную (EAGER). Единственное место, где ленивость формально сохранится — это JPQL-запросы, где Hibernate проигнорирует аннотацию и выполнит ленивый SELECT.

2. Как ведет себя `FetchMode.SUBSELECT`, если исходный список сущностей был отфильтрован сложным предикатом с параметрами?

Ответ:

При использовании FetchMode.SUBSELECT Hibernate кэширует контекст запроса, с помощью которого была получена родительская пачка сущностей (включая SQL-текст условий WHERE, ORDER BY и примененные параметры запроса).
При первом обращении к коллекции любого родителя Hibernate генерирует подзапрос, вставляя сохраненное тело исходного запроса внутрь оператора IN:
```
SELECT items.* FROM order_items items 
WHERE items.order_id IN (
    SELECT o.id FROM orders o WHERE o.user_id = ? AND o.total_price > ?
);
```
Hibernate автоматически повторно биндит те же самые значения параметров.
Подводный камень: Если исходный запрос содержал пагинацию (LIMIT / OFFSET), некоторые СУБД (например, старые версии MySQL) не поддерживают конструкции вида WHERE id IN (SELECT ... LIMIT N). В таких случаях Hibernate вынужден либо генерировать временные таблицы, либо падать с синтаксической ошибкой SQL.

3. Чем отличается пакетная выборка через `@BatchSize` от стратегии `FetchMode.SUBSELECT`?

Ответ:

Механизм генерации SQL:
- @BatchSize(size = 20) берет до 20 физических первичных ключей уже находящихся в оперативной памяти объектов Order и подставляет их в литеральный список: WHERE order_id IN (1, 2, 3, ... 20).
- SUBSELECT не перечисляет ID явно, а повторно выполняет весь исходный запрос родителей в виде вложенного подзапроса: WHERE order_id IN (SELECT id FROM ...).
Масштабируемость:
- @BatchSize работает предсказуемо всегда, даже если сущности были загружены из разных источников, добавлены в сессию вручную или получены по частям.
- SUBSELECT работает только в том случае, если вся пачка родителей была извлечена единым общим запросом.

4. Что такое `@LazyGroup` в Hibernate, и как эта аннотация расширяет стандартные стратегии выборки?

Ответ: Аннотация @LazyGroup используется совместно с плагином Bytecode Enhancement для тонкой настройки ленивой загрузки базовых колонок (@Basic(fetch = FetchType.LAZY)):

По умолчанию все ленивые базовые поля сущности инициализируются одновременно при первом обращении к любому из них.

С помощью @LazyGroup("groupName") разработчик может разбить тяжелые поля на независимые группы:

@Lob @Basic(fetch = FetchType.LAZY)
@LazyGroup("photos")
private byte[] avatar;

@Lob @Basic(fetch = FetchType.LAZY)
@LazyGroup("documents")
private byte[] passportScan;

Обращение к getAvatar() загрузит из БД только колонку аватара, оставив скан паспорта незагруженным вторым ленивым полем, что позволяет ювелирно контролировать расход сетевого трафика.

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

30-секундный ответ (Elevator Pitch)

«В Hibernate стратегии загрузки разделяются на два уровня: FetchType в JPA определяет момент загрузки (LAZY — по требованию, EAGER — немедленно), а FetchMode в Hibernate определяет способ формирования SQL-запроса (SELECT — вторичные запросы, JOIN — выборка через объединение таблиц, SUBSELECT — подзапрос WHERE IN для коллекций). В продакшене статический FetchMode почти не используется, так как FetchMode.JOIN ломает ленивую загрузку и игнорируется в JPQL. Вместо этого применяется стратегия динамической выборки: базовый маппинг всегда LAZY, а в конкретных запросах используются JOIN FETCH, @EntityGraph, либо глобальный batch fetching через hibernate.default_batch_fetch_size».

Ключевые метрики для Production-мониторинга

Количество сетевых round-trips к СУБД на транзакцию.
Соотношение запросов SELECT к объединенным JOIN в профайлере SQL (p6spy).
Размер результирующего трафика между базой данных и приложением (JDBC Network Egress).

Красные флаги (Чего говорить НЕЛЬЗЯ)

❌ «FetchType и FetchMode — это синонимы, просто один из JPA, а другой из Hibernate» — FetchType определяет время выборки (когда), а FetchMode — форму SQL-запроса (как).
❌ «Если написать @Fetch(FetchMode.JOIN), то запрос SELECT o FROM Order o сделает JOIN» — JPQL полностью игнорирует аннотацию @Fetch(FetchMode.JOIN).
❌ «FetchMode.SUBSELECT можно ставить на связь @ManyToOne» — SUBSELECT применим исключительно к коллекциям (*ToMany).
❌ «@BatchSize — это одно из значений enum FetchMode» — Нет, это отдельный механизм пакетной загрузки.

🟢 Junior Level

Фундаментальное разделение: «Когда» против «Как»

Основные стратегии Hibernate FetchMode

🟡 Middle Level

Детальный разбор стратегий FetchMode

1. FetchMode.SELECT

2. FetchMode.JOIN

3. FetchMode.SUBSELECT