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

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

Стратегии решения:

1. JOIN FETCH (JPQL или Criteria API): Наиболее эффективный способ загрузить все данные одним запросом.

   @Query("SELECT DISTINCT o FROM Order o JOIN FETCH o.items WHERE o.customer.id = :customerId")
   List<Order> findOrdersWithItemsByCustomer(@Param("customerId") Long customerId);

   Используйте DISTINCT, чтобы избежать дубликатов корневых сущностей.

2. EntityGraph: Декларативный способ указать, какие ассоциации нужно загрузить eagerly.

   @EntityGraph(attributePaths = {"items", "customer.address"})
   @Query("SELECT o FROM Order o WHERE o.id = :id")
   Optional<Order> findByIdWithDetails(@Param("id") Long id);

3. Batch Fetching (@BatchSize): Оптимизирует N+1, загружая коллекции не по одной, а пачками.

   @Entity
   public class Customer {
       @OneToMany(mappedBy = "customer")
       @BatchSize(size = 10)
       private Set<Order> orders;
   }

   Вместо N запросов будет выполнено N / size запросов.

4. DTO Projections: Для read-only сценариев можно сразу выбирать только нужные поля в DTO, минуя загрузку полных сущностей и их контекст persistence.

   @Query("SELECT new com.example.dto.OrderSummary(o.id, o.total, c.name) " +
          "FROM Order o JOIN o.customer c")
   List<OrderSummary> findOrderSummaries();

Выбор стратегии: JOIN FETCH — для глубокой загрузки по известным критериям, @BatchSize — для глобальной оптимизации, EntityGraph — для гибкости, DTO — для сложных отчетов.