Есть примерно такой запрос:

ВЫБРАТЬ
    ВложенныйЗапрос.Период КАК Период,
    ВложенныйЗапрос.Регистратор КАК Регистратор,
    ВложенныйЗапрос.Организация КАК Организация,
...

который примерно за 1.5 сек выдает результа в 50 тыс. строк

Если этот запрос изменить на

ВЫБРАТЬ ПЕРВЫЕ 1000000
    ВложенныйЗапрос.Период КАК Период,
    ВложенныйЗапрос.Регистратор КАК Регистратор,
    ВложенныйЗапрос.Организация КАК Организация,
...

то те же 50 тыс. строк получаются за 0.7 сек то есть в два раза быстрее

Как это можно объяснить?

ПС. Сами запросы и измерения выполнялись в некой консоли запросов.

1. недокешировал
2. оптимизатор плана прогоняет лимит на вложенный и выборка в нем меньше
3. лимит добавляет ордер бай в 1с автоматом и там что то оптимизируется

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

(1) (2) #ПродолжаюНаблюдения: первый пункт отпадает.
Если лимит увеличить до 100 млн. то время выполнения 1.2 сек в среднем. т.е. увеличилось, но не до предела.
выборка во вложенном запросе 90 тыс. строк, поэтому и второй пункт не проходит.
  Остается только внутренняя оптимизация 1с.

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

(3) нет..это полная хрень.
Очисти все кеши, обнови статистику и запускай наеборот запросы. Будешь приятно удивлен
Или хотя бы замеры делай каждый раз после удаления кешей и обновления статистики.

А так, смотри реальный план выполнения запросо.. там почти есть все ответы

(0)
Какая СУБД?
(правда, ответа на вопрос у меня всё равно нет, но вдруг станет скучно - пойду сам попробую)

Поверхностно - в oracle, например, можно написать хинт FIRST_ROWS - и при этом план построится сильно по другому.
MsSql, наверное, может вместо хинта использовать просто TOP.

(6) ага.. ща выеснится, что это файловая

(4) Не-е, чистить кеши, обновлять статистику это лабораторные опыты. На практике в реальной эксплуатации этого сделать невозможно. Запрос-то будет использоваться в реальной обработке, которую будут запускать обычные пользователи. Операнд ПЕРВЫЕ 1000000 уменьшит время выполнения у них или нет. Вот в чем вопрос.

(7) Вполне может быть.
Там иногда запросы с GROUP BY (и без агрегатных функций) выполняются (в несколько раз) быстрее чем такие же с DISTINCT.
Хотя вроде это одно и тоже должно быть.

Усложнил запрос согласно бизнес-логики соединениями с дополнительными таблицам, индексами, связями и #ПродолжаюНаблюдения:
БАза серверная. на сервере только тестовые базы для отладки. Результирующая таблица во всех случаях одинаковая.

Лимит   59 999 Время 1,3 сек
Лимит   99 999 Время 1,4 сек
Лимит  999 999 Время 4,9 сек
Лимит  9999 999 Время 6,2 сек
Лимит 99999 999 Время 76,2 сек!

Безлимит - Время 1,3 сек!!  Ничего не понимяю(с)

Но на всякий случай решил использовать безлимит.

(10) в реальной практике запрос выполняется первый раз 5 секунд, второй раз 0.5 секунд. Потому что после 1-го раза закешировалось. Поэтому чтобы получить реальный результат, а не фуфло, как у тебя, нужно так: выполнил запрос, чистишь кеш, перезагружаешь сервер, выполняешь второй запрос. Тогда получишь реальные цифры.

(10) тебе толковые люди говорят: смотри план запроса, а ты продолжаешь гадать

(8) > уменьшит время выполнения у них или нет. Вот в чем вопрос.
А хрена ты его задаешь нам, а не реальным пользователям?

(10) на первые ххх опирается оптимизатор при выборе плана.

если на результат не влияет, то лучше не надо, надо данные держать в кэше и статистику актуальной.

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