LIMIT ограничивает количество возвращаемых строк
LIMIT — это самый простой «регулятор» в SQL: он говорит SQLite «верни мне не больше стольких-то строк». Допишите его в конце SELECT — и получите не больше указанного числа результатов. Может быть и меньше, если в таблице просто не наберётся столько строк.
Возвращаются первые три строки. Только вот какие именно? В этом и подвох — без ORDER BY SQLite сам решает, в каком порядке отдавать данные. Сегодня это может быть порядок вставки, а завтра, после обновления или изменения индекса, — уже что-то другое. LIMIT сам по себе вполне годится, чтобы «глянуть пару строк для примера», но как только порядок начинает иметь значение — его нужно задать явно.
OFFSET: пропускаем строки с начала
Связка LIMIT и OFFSET позволяет вытащить срез откуда-то из середины результата. OFFSET k отбрасывает первые k строк, а LIMIT n затем возвращает не более n строк из того, что осталось.
То есть «пропусти две строки и верни следующие две» — это будут 3-я и 4-я строки в отсортированном результате. Запомните логику: WHERE фильтрует, ORDER BY сортирует, OFFSET пропускает, LIMIT ограничивает. Порядок именно такой, и каждый шаг важен.
Пагинация в SQLite немыслима без ORDER BY
Самый частый сценарий для LIMIT и OFFSET — это пагинация, когда длинный список нужно разбить на страницы, скажем, по 20 строк. Первая страница — LIMIT 20 OFFSET 0, вторая — LIMIT 20 OFFSET 20, и так далее.
На что здесь стоит обратить внимание. Во-первых, ORDER BY — это не опция, а необходимость: без него «вторая страница» вообще не имеет смысла, и строки могут перетасовываться между запросами. Во-вторых, в ключе сортировки рядом с основным полем стоит id как тай-брейкер. Если у двух постов совпадает created_at, нужна уникальная колонка, чтобы порядок был детерминированным, иначе строки могут меняться местами и одна и та же запись «перетечёт» на соседнюю страницу.
Запомните простое правило: сортируйте либо по уникальному полю, либо по основному столбцу плюс уникальный тай-брейкер.
Сокращённая форма: LIMIT n, m
В SQLite сохранён старый синтаксис через запятую — для совместимости с MySQL: LIMIT offset, count. По смыслу это то же самое, что и LIMIT count OFFSET offset, только порядок аргументов обратный, и его легко перепутать.
-- Эти два запроса эквивалентны:
SELECT * FROM books LIMIT 10 OFFSET 20;
SELECT * FROM books LIMIT 20, 10; -- сначала смещение, потом количество
Второй вариант короче, но многих сбивает с толку: люди ждут, что первое число — это количество строк. Лучше держаться LIMIT n OFFSET k — запись явная и читается слева направо.
OFFSET без LIMIT: трюк с LIMIT -1
Сам по себе OFFSET использовать нельзя — грамматика SQLite требует, чтобы он шёл после LIMIT. Как же тогда сказать «пропусти первые 10 строк и отдай всё остальное»? Принятое решение — LIMIT -1, которое SQLite понимает как «без верхнего предела».
Любой отрицательный LIMIT делает то же самое, просто -1 — это устоявшийся идиом. Чаще всего такое встречается в скриптах, которые проходят по результату постранично и на последней итерации хотят сказать «отдай мне всё, что осталось».
Подводный камень производительности OFFSET
Вот о чём обычно молчат, пока сами на это не наткнёшься: OFFSET не заставляет SQLite пропускать работу — он заставляет SQLite пропускать вывод. Чтобы вернуть строки с 10 001-й по 10 020-ю, движок всё равно внутри себя пробегает первые десять тысяч строк, прежде чем начать отдавать результат. Маленькие смещения практически бесплатны, а вот OFFSET в десятки и сотни тысяч заметно проседает по скорости.
Для глубокой пагинации стандартное решение — keyset-пагинация: вместо «пропусти N строк» мы запоминаем ключ сортировки последней показанной строки и просим «дай строки после вот этой».
Каждая страница делает индексированный поиск вместо того, чтобы пролистывать всё, что было до неё. Цена вопроса: нельзя прыгнуть сразу на «страницу 47» — только идти вперёд по данным. Для бесконечной ленты и курсоров в API это как раз то, что нужно.
Пагинация через OFFSET отлично подходит для админок и небольших выборок. Но если данные растут бесконечно — берите keyset-пагинацию.
Разбираем на примере
Соберём всё вместе — запрос с пагинацией, фильтрацией, сортировкой и детерминированным тай-брейкером:
Отфильтровываем офисные товары, сортируем по цене по возрастанию, а в качестве тай-брейкера используем имя, и берём первые две строки. Чтобы получить вторую страницу, меняем OFFSET 0 на OFFSET 2. Запрос короткий, но каждое выражение в нём работает на результат.
Дальше: DISTINCT
LIMIT определяет, сколько строк вернётся, а DISTINCT — вернутся ли дубликаты вообще. Это следующее выражение в арсенале SELECT, и его обманчиво легко применить не туда, куда нужно. Об этом — на следующей странице.
Часто задаваемые вопросы
Что делает LIMIT в SQLite?
LIMIT n ограничивает количество строк, которые вернёт SELECT, числом n. Важный момент: он применяется уже после WHERE, GROUP BY и ORDER BY — то есть режется итоговая выборка, а не то, что сканирует движок. Например, SELECT * FROM users LIMIT 10 отдаст не больше десяти строк.
Как OFFSET работает вместе с LIMIT?
OFFSET k пропускает первые k строк результата, и только потом начинает считать LIMIT. То есть LIMIT 10 OFFSET 20 вернёт строки с 21-й по 30-ю. Под капотом SQLite всё равно проходит по всем пропущенным строкам — поэтому большие значения OFFSET и работают медленно.
Можно ли использовать OFFSET без LIMIT?
Напрямую — нет: OFFSET существует только как часть конструкции LIMIT. Обходной путь — LIMIT -1 OFFSET k, где -1 означает «без верхней границы». SQLite пропустит k строк и вернёт всё остальное. Полезный костыль, который стоит запомнить.
Зачем для пагинации обязательно нужен ORDER BY?
Без ORDER BY SQLite вправе отдавать строки в любом порядке, и этот порядок может меняться от запроса к запросу. В итоге пагинация ломается: одна и та же запись может появиться и на первой, и на третьей странице — или вовсе исчезнуть. Поэтому LIMIT/OFFSET всегда нужно сочетать с ORDER BY по стабильной уникальной колонке.
