Выполнится ли JOIN FETCH с отложенным стартом?

JOIN FETCH с отложенной загрузкой (Lazy Loading)

Этот вопрос касается взаимодействия между явной инструкцией загрузки (JOIN FETCH) и стратегией отложенной загрузки (FetchType.LAZY). Ответ: JOIN FETCH ПЕРЕОПРЕДЕЛЯЕТ отложенную загрузку и выполнит загрузку ассоциации.

Основной принцип

JOIN FETCH всегда загружает данные EAGERLY (активно), даже если в маппинге установлено FetchType.LAZY. Это потому что:

1. JOIN FETCH — это явная инструкция в JPQL/HQL запросе
2. Явная инструкция имеет приоритет над аннотацией на сущности
3. JOIN FETCH используется именно для избежания N+1 problem при отложенной загрузке

Пример 1: Базовый случай с отложенной загрузкой

@Entity
public class Author {
    @Id
    private Long id;
    private String name;
    
    // Отложенная загрузка (по умолчанию для OneToMany)
    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    private Set<Book> books;
}

@Entity
public class Book {
    @Id
    private Long id;
    private String title;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Author author;
}

// Без JOIN FETCH - LAZY загрузка
Author author = entityManager.createQuery(
    "SELECT a FROM Author a WHERE a.id = :id",
    Author.class
).setParameter("id", 1L).getSingleResult();

// author загружен, но books ещё нет
// При обращении к author.getBooks() будет отдельный запрос

// С JOIN FETCH - EAGER загрузка
Author author = entityManager.createQuery(
    "SELECT a FROM Author a JOIN FETCH a.books WHERE a.id = :id",
    Author.class
).getSingleResult();

// author И books загружены в одном запросе
// author.getBooks() не вызывает дополнительный SQL запрос

Пример 2: SQL запросы разные

// Без JOIN FETCH
SELECT a FROM Author a WHERE a.id = 1

// SQL запрос:
SELECT author.id, author.name FROM authors author WHERE author.id = 1

// Затем при обращении к author.getBooks():
SELECT book.id, book.title FROM books book WHERE book.author_id = 1


// С JOIN FETCH
SELECT a FROM Author a JOIN FETCH a.books WHERE a.id = 1

// SQL запрос (один запрос вместо двух):
SELECT author.id, author.name, book.id, book.title 
FROM authors author 
LEFT JOIN books book ON author.id = book.author_id 
WHERE author.id = 1

Пример 3: N+1 Problem решается JOIN FETCH

// ❌ N+1 Problem - медленно
List<Author> authors = entityManager.createQuery(
    "SELECT a FROM Author a",
    Author.class
).getResultList(); // 1 запрос

for (Author author : authors) {
    System.out.println(author.getBooks()); // N запросов (по одному на каждого автора)
}

// Итого: 1 + N запросов


// ✅ JOIN FETCH решает проблему
List<Author> authors = entityManager.createQuery(
    "SELECT DISTINCT a FROM Author a LEFT JOIN FETCH a.books",
    Author.class
).getResultList(); // 1 запрос с JOIN

for (Author author : authors) {
    System.out.println(author.getBooks()); // Без дополнительных запросов
}

// Итого: 1 запрос

Пример 4: Декартов продукт при JOIN FETCH One-to-Many

@Entity
public class Department {
    @Id
    private Long id;
    private String name;
    
    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    private Set<Employee> employees;
}

@Entity
public class Employee {
    @Id
    private Long id;
    private String name;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Department department;
}

// JOIN FETCH может создать дублирование
List<Department> departments = entityManager.createQuery(
    "SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.id = 1",
    Department.class
).getResultList();

// Если у Department 1 есть 3 сотрудника, результат может содержать
// тот же Department объект 3 раза (один раз на каждого Employee)
// Решение: использовать DISTINCT в JPQL

Пример 5: Multiple JOIN FETCH

@Entity
public class Order {
    @Id
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Customer customer;
    
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    private Set<OrderItem> items;
}

@Entity
public class Customer {
    @Id
    private Long id;
    private String name;
}

@Entity
public class OrderItem {
    @Id
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Order order;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Product product;
}

// Можно сделать несколько JOIN FETCH
List<Order> orders = entityManager.createQuery(
    "SELECT DISTINCT o FROM Order o " +
    "LEFT JOIN FETCH o.customer " +
    "LEFT JOIN FETCH o.items " +
    "LEFT JOIN FETCH o.items.product",
    Order.class
).getResultList();

// Все связанные данные загружены одним запросом

Пример 6: LEFT JOIN FETCH vs INNER JOIN FETCH

// LEFT JOIN FETCH - вернёт Author даже если нет Books
SELECT DISTINCT a FROM Author a LEFT JOIN FETCH a.books

// INNER JOIN FETCH - вернёт только Author с Books
SELECT a FROM Author a INNER JOIN FETCH a.books

Spring Data JPA аннотация

@Repository
public interface AuthorRepository extends JpaRepository<Author, Long> {
    
    // Используем @Query с JOIN FETCH
    @Query("SELECT DISTINCT a FROM Author a LEFT JOIN FETCH a.books")
    List<Author> findAllWithBooks();
    
    // EntityGraph альтернатива
    @EntityGraph(attributePaths = {"books"})
    List<Author> findAll();
}

Ограничения JOIN FETCH

1. Не работает с pagination - при использовании setFirstResult/setMaxResults результаты непредсказуемы
2. Декартов продукт - One-to-Many может дублировать родительский объект
3. Производительность - если связанных данных очень много, загрузка может быть медленнее

Когда использовать JOIN FETCH

1. Избежание N+1 Problem - когда нужно загрузить связанные данные
2. Критичная производительность - одним запросом лучше, чем N+1
3. Отложенная загрузка в сессии - вне сессии LAZY ассоциации вызовут LazyInitializationException
4. Не используется pagination - для обхода декартова продукта

Вывод

JOIN FETCH ВСЕГДА выполнится и переопределит FetchType.LAZY установленный на сущности. Это явная инструкция разработчика, которая имеет приоритет над конфигурацией маппинга. JOIN FETCH — главный инструмент для оптимизации запросов в Hibernate и решения N+1 Problem.