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

Да ты посмотри, какая классика подъехала! Проблема N+1, блядь. Это ж как в том анекдоте: приходишь за одним пивом, а уходишь с десятью, потому что каждый раз надо новую открывать. Так и тут, сука.

Представь: ты грузишь один заказ, а Hibernate такой: "О, а давай-ка я для каждого товара в заказе отдельный запрос в базу сделаю, а то скучно!" И понеслась: один главный запрос и потом ещё N штук — по одному на каждую хуйню в коллекции. Производительность, понятное дело, летит в пизду. Овердохуища запросов.

Но не всё так плохо, есть же способы этого конченого попугая приструнить.

Первая и самая мощная фишка — JOIN FETCH. Это как взять всё нужное одним махом, без лишних телодвижений. Берёшь JPQL и прямо в запросе говоришь: "Эй, дружок, когда будешь заказы тащить, прихвати сразу и все items, не ссы".

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

Только DISTINCT не забудь, а то из-за джойнов тебе одни и те же заказы как сумасшедшие размножаться начнут. Будет не N+1, а N*M, тоже веселуха.

Вторая — EntityGraph. Это типа декларативный способ намекнуть, что тебе надо не просто сущность, а сущность со всеми потрохами. Как будто говоришь: "Мне не просто Order, а Order с items и customer.address, чтоб всё сразу, в одном флаконе".

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

Удобно, элегантно, не надо в JPQL эти джойны расписывать.

Третья — Batch Fetching, она же @BatchSize. Это для ленивых, но умных. Вместо того чтобы дёргать базу за каждой отдельной коллекцией, ты говоришь: "Ладно, грузи, но пачками, по 10 штук за раз!".

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

Вместо N отдельных запросов получишь N/10. Не идеально, но уже терпимо, особенно если не знаешь заранее, какие именно связи понадобятся.

Ну и четвёртый способ — DTO Projections. Это когда тебе нахуй не нужна вся эта ORM-магия с контекстом, трекингом изменений и прочей мишурой. Тебе нужны только данные для отчёта или отображения. Тогда ты сразу из базы выгребаешь только нужные поля в свой простой объект.

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

Чисто, быстро, никакого N+1, потому что никаких ленивых коллекций — только то, что попросил.

Так какую же выбрать, блядь? Да смотри по обстановке:

• JOIN FETCH — когда чётко знаешь, что и как глубоко надо загрузить по конкретному критерию. Мощно и эффективно.
• @BatchSize — для глобальной, фоновой оптимизации, когда не можешь везде JOIN FETCH воткнуть.
• EntityGraph — когда хочется гибкости и переиспользования.
• DTO — когда пишешь какую-нибудь ебучую отчётность или сложную вьюху, где ентити целиком только память жрать будут.

Главное — понимать, что происходит под капотом, а не просто аннотации тыкать наугад. А то будет не решение проблемы, а пиздопроебибна какая-нибудь.