Оптимизация запросов в JPA: избегайте FetchType.EAGER

Стратегии извлечения данных (fetching strategies) оказывают значительное влияние на производительность приложения. Hibernate предлагает четыре стратегии: JOIN, SELECT, SUBSELECT и BATCH. По умолчанию, JPA использует LAZY для связей «один-ко-многим» и «многие-ко-многим», и EAGER для связей «многие-к-одному» и «один-к-одному». При этом, EAGER загрузка не может быть переопределена в запросах, что ограничивает гибкость, и часто приводит к избыточной загрузке данных и замедлению работы.

Использование EAGER приводит к тому, что связанные сущности загружаются всегда, даже если они не требуются в конкретном запросе. Например, при запросе Product, связанная Company, отмеченная как EAGER, будет извлекаться всегда с использованием JOIN, хотя может и не понадобиться для текущей операции. Это повышает сложность запроса и время выполнения. При запросах через JPQL или Criteria API, EAGER ассоциации приводят к генерации отдельных запросов к базе данных для каждой связанной сущности, что также не оптимально.

Hibernate Criteria API, в отличие от JPA Criteria API, по умолчанию использует JOIN FETCH для EAGER ассоциаций, что может показаться более эффективным. Однако, при EAGER коллекции, Hibernate Criteria может генерировать дубликаты родительских сущностей из-за объединения дочерних объектов. Для решения этой проблемы следует использовать CriteriaSpecification.DISTINCT_ROOT_ENTITY, чтобы гарантировать уникальность результирующих объектов.

Лучшая практика – использовать LAZY стратегию по умолчанию и настраивать стратегию загрузки для каждого конкретного запроса. Это позволяет оптимизировать запросы в соответствии с требованиями каждого бизнес-процесса, обеспечивая максимальную производительность и гибкость, и позволяет избегать как неявных ошибок, так и проблем производительности, которые возникают при бездумном использовании EAGER.

Источник: ms_shcherbach