Проблема N+1 в Hibernate на собеседовании

Откуда берутся лишние запросы

Лишние запросы — не ошибка в джойнах, а прямое следствие того, как устроена ленивая загрузка. Связи по умолчанию ленивые, и вместо реального объекта Hibernate кладёт в поле прокси — заглушку, которая знает, как себя догрузить, но пока пуста. Пока к прокси не обращаются, он ничего не делает. Как только код читает поле, прокси идёт в базу.

Отсюда описание, которое точнее определения: N+1 — это симптом того, что объекты инициализируются по требованию, а требование возникает в цикле. Загрузили список из ста заказов — один запрос. Прошлись по списку и у каждого спросили покупателя — сто запросов, по одному на итерацию.

Из этого механизма выводится наблюдение, которое на собеседовании работает лучше любого определения: обращение к идентификатору связанной сущности запроса не порождает, а обращение к любому другому её полю — порождает. Причина в том, где лежит внешний ключ. Значение идентификатора уже есть в строке родительской таблицы, и прокси может отдать его, не ходя в базу; имя, дата и всё остальное живут в другой таблице, и за ними приходится идти.

Оговорка, которая отличает понимание от заученного правила: это верно, когда внешний ключ хранится в родительской таблице. На связи «многие ко многим» через таблицу-связку идентификатор так же бесплатно взять неоткуда.

Как увидеть проблему

Обнаружить N+1 сложнее, чем обычное узкое место, и причина в том, что каждый отдельный запрос быстрый. Мониторинг медленных запросов такую картину не покажет: сто запросов по три миллисекунды не попадут ни в один порог, а в сумме дадут треть секунды на ровном месте.

Работает подход, который смотрит не на длительность, а на количество. Инженеры, разбирающие эту проблему, описывают его так: для каждого метода задаётся ожидаемое число обращений к базе, и всё, что сверх него, считается дефектом. Проверка при этом становится обычным тестом — она не измеряет время и потому не зависит ни от машины, ни от объёма данных.

Второй способ, который стоит назвать, — включить показ SQL и просто посмотреть на лог. Он грубее, зато не требует ничего, кроме одной настройки, и на собеседовании его достаточно.

Полезно назвать и признак, по которому N+1 отличается от просто медленного запроса: количество запросов растёт вместе с количеством строк в выборке. Это то, что проверяется одним экспериментом — загрузить десять записей вместо ста и посмотреть, изменилось ли число обращений в десять раз.

Четыре способа лечения

Способов починки в Hibernate четыре, и они решают задачу по-разному — это и есть содержание ответа, потому что назвать один из них умеет каждый.

Join fetch. Явное указание в запросе подтянуть связь тем же джойном. Один запрос вместо N+1, всё приезжает сразу. Самый прямой способ, и именно его называют решением почти все материалы по теме, — у него есть цена, о ней следующая секция.

Entity graph. Декларативное описание того, какие связи должны быть загружены, — задаётся отдельно от запроса и применяется к нему. Отличие от join fetch не в результате, а в том, что стратегия выборки перестаёт быть частью текста запроса: один и тот же запрос можно выполнить с разными графами. EntityGraph — часть контракта Jakarta Persistence, а не только Hibernate.

Batch fetching. Вместо того чтобы догружать связи по одной, Hibernate догружает их пачками заданного размера. Запросов остаётся не один, но вместо ста получается, скажем, десять. Настраивается размером пачки на связи или сущности.

Subselect fetching. Связи для всех загруженных родителей догружаются одним отдельным запросом, использующим подзапрос исходной выборки. Итого два запроса: один за родителями, один за всеми их коллекциями сразу.

Критерий выбора формулируется коротко: join fetch и entity graph убирают запросы, объединяя данные в один результат; batch и subselect оставляют отдельный запрос, но перестают умножать его на число строк. Первая пара выигрывает по числу обращений, вторая — по форме результата.

Чем платит join fetch

Присоединение коллекции джойном меняет форму результата, и это тот эффект, о котором забывают чаще всего. Одна строка родителя, у которого пять элементов в коллекции, превращается в пять строк результата: база возвращает декартово произведение, а не список родителей. Сущность потом соберётся правильно, но строк в наборе будет больше, чем записей.

Из этого следует конфликт, о котором документация Hibernate предупреждает прямо: join fetch коллекции плохо совместим с постраничной выборкой. Ограничение «взять двадцать штук начиная с сорок первой» применяется к строкам результата, а строк больше, чем сущностей, — и страница получается не той, которую ожидали. Рекомендация документации для этого случая — использовать batch или subselect вместо джойна.

Отсюда практический вывод: если в выборке есть пагинация, join fetch коллекции не подходит. Ограничение касается именно коллекций — присоединение связи «многие к одному» строки не размножает и с пагинацией уживается.

Обратная сторона той же ленивости стоит того, чтобы её назвать: если недогрузить связь и обратиться к ней после закрытия контекста персистентности, вместо лишних запросов вы получите LazyInitializationException. N+1 и это исключение — две крайности одной настройки: в первом случае данные догружаются слишком часто, во втором — попытка догрузить приходит слишком поздно.