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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем платит join fetch §

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

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

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

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