Работали ли вы с лимитированием в SQL

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

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

Как отвечать

Покажите запрос целиком, а не одну строчку:

select id, created_at
from orders
order by created_at desc, id desc
limit 20 offset 40;

Объясните смысл: пропускаем сорок строк и берём двадцать, то есть третью страницу по двадцать записей. Сортировка обязательна, причём по полю, которое однозначно упорядочивает строки, иначе при равных значениях база вправе вернуть их в любом порядке. Упомяните диалекты: limit и offset работают в PostgreSQL и MySQL, в MS SQL это offset ... rows fetch next ... rows only или top, в Oracle fetch first ... rows only.

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

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

Опускают сортировку и считают порядок гарантированным. Тест то зелёный, то красный, потому что база сменила план запроса, а не потому, что появился дефект.

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

Тестируют только первую страницу. Большое смещение заставляет базу прочитать и выбросить все пропущенные строки, поэтому на миллионе записей последние страницы открываются заметно дольше первых, и об этом узнают уже в эксплуатации.