Краткий ответ

Чтобы получить первые строки по заданному критерию, SQL логически сначала формирует набор данных, затем сортирует его, а после этого применяет ограничение количества строк. Если ограничить строки до сортировки, результатом станет сортировка случайного или предварительно выбранного поднабора, а не выбор лучших строк всей выборки.

Например, для получения трёх самых дорогих товаров ограничение должно применяться к результату сортировки:

SELECT product_id, price
FROM products
ORDER BY price DESC, product_id
FETCH FIRST 3 ROWS ONLY;

Здесь product_id добавлен как уникальный дополнительный критерий, чтобы порядок строк при одинаковой цене был детерминированным.

Исторический контекст

Реляционная модель не задаёт естественный порядок строк. Поэтому сортировка в SQL является отдельным логическим требованием, а не свойством таблицы или результата выборки по умолчанию.

Возможность ограничивать результат появилась как практическая необходимость для постраничного вывода, поиска наиболее значимых записей и уменьшения объёма передаваемых данных. Эти задачи требуют определить, какие строки считаются первыми, поэтому ограничение должно рассматриваться вместе с сортировкой.

Постановка проблемы

Запрос без явной сортировки не гарантирует порядок строк, даже если в конкретном запуске строки выглядят отсортированными. План выполнения, индекс, параллелизм или изменение данных могут привести к другому порядку.

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

Подробное решение

Логически результат строится так: применяются источники данных и фильтры, затем выполняются группировка и фильтрация групп, формируется список выбранных столбцов, после чего применяется сортировка и ограничение результата. Конкретная СУБД может физически выполнить операции в другом порядке, например использовать индекс или алгоритм поиска топ-N, но итог должен соответствовать логической семантике.

ORDER BY определяет, какие строки считаются первыми. FETCH FIRST, OFFSET или диалектный аналог ограничивают уже упорядоченный результат. Само наличие ограничения не создаёт порядок, поэтому ограничение без ORDER BY не подходит для воспроизводимого топа или пагинации.

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

OFFSET удобен для простых страниц, но на больших смещениях СУБД может просматривать и пропускать множество предыдущих строк. Keyset-пагинация обычно эффективнее: следующая страница выбирается относительно последнего ключа предыдущей страницы, но такой подход требует подходящего индекса и не поддерживает произвольный переход на далёкую страницу столь же просто.

Ситуация из практики

В интернет-магазине нужно показывать по десять товаров с максимальным рейтингом. Команда сначала получает десять строк без сортировки, а затем сортирует их в приложении. В результате товар с высоким рейтингом может отсутствовать на странице, потому что он не попал в первоначальный поднабор.

Вариант с сортировкой в приложении прост, но неверен по смыслу и требует передачи лишних данных. Вариант с ограничением без ORDER BY дешевле на вид, но не гарантирует ни состав, ни порядок результата.

Выбран запрос с сортировкой по рейтингу и уникальному идентификатору, после чего применяется ограничение. Для следующих страниц при большом объёме данных использована keyset-пагинация, потому что она не требует каждый раз пропускать все предыдущие строки.

Что кандидаты часто упускают

Гарантирует ли сортировка по одному столбцу стабильный порядок строк с одинаковым значением?

Нет. Если несколько строк имеют одинаковое значение сортируемого столбца, их взаимный порядок не определён, пока не добавлен дополнительный критерий. Для стабильного результата обычно используют уникальный идентификатор в конце списка сортировки.

Может ли СУБД физически ограничить строки до полной сортировки, не нарушив результат?

Да, если это оптимизация, сохраняющая требуемую семантику. Например, СУБД может применить индекс по нужному порядку или алгоритм top-N и не сортировать весь набор в памяти. Это не означает, что логически ограничение стало применяться раньше сортировки: оптимизатор обязан вернуть тот же результат, который задаёт логический порядок запроса.

Почему ограничение без ORDER BY особенно опасно при постраничной выдаче?

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