Dimitry SibiryakovmiksoftНо одно дело сформируется на миллионы записей и совсем другое - на сотню.
Не бывает в природе. Кляуза ROWS чисто технически абсолютно эквивалентна ограниченному
фетчу. Так что и формирование базового резалт-сета в точности одинаково.


Это, конечно же, совершенно неверно.

Простой пример:
Выборка по JOIN'у двух примерно равноразмерных больших таблиц, объединение по проиндексированным ключам.
Вменяемая СУБД конечно же сообразит, что при запрошенном полном резалт-сете нужно сделать какой-нибудь HASH JOIN, требующий предварительных подготовительных операций и далеко не сразу начинающий "выплёвывать" результаты.
На полном наборе данных это будет ЗНАЧИТЕЛЬНО быстрее NLJOIN, выдёргивающего записи по индексу по одной из random'ных мест "внешней" таблицы.
Или пусть не HASH, а MERGE JOIN, требующий предварительного полного сканирования и сортировки объединяемых таблиц, который тоже будет значительно быстрее NLJOIN.

При наличии информации о том, что выборка ограничена сотней записей, будет "в лоб" применён Nested Loop JOIN с немедленной отдачей результатов.


При наличии ORDER BY всё несколько интереснее, но тем не менее все равно есть существенное отличие . Могут быть использованы плохие для полного result set'а планы, но сразу начинающие отдавать записи.


Другое дело, что что с точки зрения как реляционной теории, так и правильногоо проектирования конструкции типа "отдай то, не знаю чего", часто и лежащие под fetch first... у ленивых разработчиков/бизнес-аналитиков, бессмысленны.
Тем не менее, ограниченная размером вывода выборка по упорядоченному списку, да и просто случайная выборка (sample) вполне адекватно могут отражать существующие "бизнес"-задачи.

Семантически FETCH FIRST N ROWS ONLY можно заменить соответствующими OLAP функциями с ограничением выборки предикатом в WHERE. По мне это красивее, но заставлять разработчиков использовать "... ROW_NUMBER() OVER(...) as RNUM ... WHERE RNUM < ..." вместо более короткого fetch first ... особого смысла не вижу (за некоторыми "но").