может логичнее select firstOnly firstFast, вместо select firstOnly

[AndyD]

2 Владимир Максимов

Во-первых, эти хинты зависят от сервера б/д
Во-вторых, от параметра CashLookup таблицы

Для MS SQL; CashLookup - EntireTable
При первом обращении на сервер отправляется запрос с хинтом OPTION(FAST n) (n - зависит от таблицы) и после этого записи фетчатся порциями по n, пока не будет закачана вся таблица (и для firstonly и для firstfast). При повтороном обрущении данные берутся из кэша

MS SQL; другие значения CashLookup
Для хинта firstonly
На сервер отправляется запрос с хинтом OPTION(FAST 2), после этого фетчится две записи и курсор закрывается
Для хинта firstfast
На сервер отправляется запрос с хинтом OPTION(FAST 1) и после этого фетчится n записей (n - зависит от таблицы). Если записи перебирать в цикле, то при выборе n+1 записи на сервер посылается запрос на фетч еще n записей и т.д.
Для совместного использования хинтов firstonly и firstfast
На сервер отправляется запрос с хинтом OPTION(FAST 1) и после этого фетчится две записи и курсор закрывается
Если не использовать хинты]
На сервер отправляется запрос с хинтом OPTION(FAST n) и после этого фетчится n записей (n - зависит от таблицы). Если записи перебирать в цикле, то при выборе n+1 записи на сервер посылается запрос на фетч еще n записей и т.д.

Для Oracle примерно то-же самое, отличие вот в чем: для EntireTable и если не указаны хинты посылается запрос как есть, для остальных значений CashLookup - хинт /*+ FIRST_ROWS */ (и для firstonly и firstfast).


2NetBus

Отвечая на первоначальный вопрос
Для MS SQL
использование совместно этих хинтов принципиального выигрыша в быстродействии не даст. При выборке больше чем одной записи - зависит от параметра n, т.е. от таблицы.

Для Oracle
совместное использование хинтов ничего не даст. В остальном -зависит от настройки оптимизатора, т.е. от параметра OPTIMIZER_MODE сервера или OPTIMIZER_GOAL сессии