JOIN FETCH в @Query, @EntityGraph на методе репозитория или пакетная загрузка (hibernate.default_batch_fetch_size). EAGER не решает — делает проблему постоянной.
А ещё @EntityGraph(attributePaths = "customer") — без изменения запроса
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
N+1 возникает потому, что ленивая связь подгружается отдельным запросом на каждую строку. Замена на EAGER — самый частый неверный ответ: количество запросов остаётся тем же, просто они выполняются всегда, включая случаи, когда связь не нужна, и проблема расползается по всему приложению. JOIN FETCH и @EntityGraph решают задачу точечно, в конкретном сценарии, где данные действительно нужны. Пакетная загрузка помогает, когда переписать запрос нельзя. Отдельно стоит помнить про подводный камень JOIN FETCH с несколькими коллекциями: возникает декартово произведение, поэтому больше одной коллекции так не тянут, а используют пакетную загрузку или отдельные запросы. И самый радикальный вариант для чтения — сразу проецировать в DTO.
Несколько верных вариантов. Подумайте, потом откройте ответ.
Абстракция репозитория, derived queries и @Query, persistence context и dirty checking, lazy/N+1 и почему DTO, а не entity.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto