Сколько запросов к базе данных выполняется для формирования одной страницы с пагинацией

Что проверяют

Слышите ли вы в вопросе слово «зависит» и умеете ли назвать, от чего именно. Заодно проверяют, смотрели ли вы когда-нибудь реальный SQL, который порождает ваш код, или верите наизусть, что репозиторий ходит в базу ровно один раз.

Как отвечать

В Spring Data отвечайте по типу возвращаемого значения:

• Page<T> это два запроса: выборка страницы и отдельный count для общего числа элементов;
• Slice<T> это один запрос: берётся на одну запись больше лимита, и по ней определяется, есть ли следующая страница;
• обычный List<T> с параметром Pageable тоже один запрос, но без сведений об общем количестве.

То есть «два» верно для типичного экрана с номерами страниц, а для бесконечной ленты второй запрос не нужен и его стоит убрать: count на большой таблице нередко дороже самой выборки.

Дальше назовите то, что ломает эту арифметику. Ленивые связи превращают одну страницу в один запрос плюс по одному на каждую строку, это классический N+1. Лечится подгрузкой через join fetch, графом сущностей или пакетной выборкой. Проверять нужно не на глаз: включите вывод SQL, а в тестах поставьте счётчик запросов через статистику Hibernate, чтобы рост количества ловился автоматически.

Где спотыкаются

Называют одно число и не оговаривают условия. Без типа возвращаемого значения и схемы связей ответ не определён, и вопрос нащупывает именно эту неопределённость.

Второе: не видят N+1, потому что на машине разработчика база маленькая и лишняя сотня запросов незаметна. На проде это первое, что укладывает страницу списка, а в логе выглядит как сотня одинаковых select с разными идентификаторами.

Третье: делают join fetch коллекции вместе с постраничной выборкой. Hibernate в этом случае не может ограничить выборку на стороне базы, тянет весь результат и режет страницу в памяти, честно предупреждая об этом в логе. Правильный путь в два шага: сначала получить идентификаторы страницы, потом загрузить их вместе с коллекциями.