Какие недостатки и особенности у пагинации через limit/offset и когда этот подход не подходит?

Пагинация через LIMIT/OFFSET — самый простой способ разбить результат на страницы: LIMIT 10 OFFSET 20 означает «пропустить 20 строк и вернуть 10». Однако у этого подхода есть две принципиальные проблемы: производительность и стабильность результата.

Проблема производительности

СУБД не умеет «прыгать» сразу к 20-й строке. Чтобы отдать OFFSET 100000, она должна прочитать и отбросить 100000 строк. Чем глубже страница, тем дороже запрос, даже если нужен всего десяток записей.

-- Медленно на больших OFFSET
SELECT * FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 100000;

-- Быстрее: keyset pagination по последнему id
SELECT * FROM posts
WHERE id < :last_id
ORDER BY id DESC
LIMIT 20;

Проблема стабильности

Если между запросами страниц данные меняются, OFFSET-пагинация даёт сдвиг: новая запись в начале сдвигает всё вниз, и пользователь видит дубликат или пропускает элемент. Это критично для лент новостей, чатов и бесконечной прокрутки.

Когда LIMIT/OFFSET не подходит

• Большие таблицы с глубокой пагинацией (миллионы строк).
• Данные часто вставляются или удаляются.
• Нужна бесконечная прокрутка или курсорная навигация.
• Требуется консистентность между страницами.

Альтернативы: keyset (cursor) pagination по уникальному упорядоченному полю, пагинация по ID, использование индексов и покрывающих запросов.

Итог: LIMIT/OFFSET удобен для небольших статичных списков и админок, но для больших и динамичных наборов данных лучше применять keyset-пагинацию.