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

[NetBus]

Часто в коде встречается, имеется в виду стандартный функционал без местных модификаций

PHP код:

select firstOnly ... <Table> 


что подразумевает, что из таблицы мы хотим получить ТОЛЬКО первую запись, и как при любом запросе, чем быстрее, тем лучше.
Возникает логичный вопрос, а почему не используется запись вида, —

PHP код:

select firstOnly firstFast ... <Table> 


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

[DenNik]

Цитата:

Изначально опубликовано NetBus

PHP код:

select firstOnly ... <Table> 


...хотим получить ТОЛЬКО первую запись, ...


Не первую, а единственную!

Изначально опубликовано NetBus

PHP код:

select firstOnly firstFast ... <Table> 


ведь в этом случае первая запись должна появиться быстрее...

Первая запись появится быстрее, только в случае если запрос возваращает несколко записей

[AndyD]

Для MS SQL эти хинты преобразуются в OPTION(FAST n). По скорости примерно одинаково.

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

Из книги: AXAPTA 3.0 Разработка бизнес-приложений. Алексей Еременко, Руслан Шашков

стр 368

FirstFast - рекомендации оптимизатору выбрать первую запись, что может заставить оптимизатор производить поиск по порядку в соответствии с индексом, вне зависимости от условия where, то есть не используя подсказки оптимизатора;

FirstOnly - рекомендация оптимизатору выбрать первую запись, вне зависимости от того, сколько записей соответствует условию запроса.

==============================================

Далее уже от себя

Если говорить "по человечески", то FirstOnly возьмет только первую попавшуюся запись из результата выборки, а FirstOnly - ускорит получение первой записи, но может сильно затормозить получение всех остальных записей выборки.

FirstOnly - имеет смысл использовать, если необходимо получить одну и только одну запись, но в выборке может оказаться несколько записей. На скорость выборки никак не влияет. Это нечто вроде аналога конструкции SELECT TOP 1 ...

FirstFast - имеет смысл использовать, если результат выборки обрабатывается в цикле (while select), где каждая итерация цикла занимает относительно много времени. В этом случае, быстро получаем первую запись и начинаем ее обрабатывать, а скорость выборки остальных записей не так уж и важна, поскольку потеря в скорости "съедается" длительной обработкой одного шага цикла. Если в результирующей выборке только одна запись, то ее использование бессмысленно.

Теперь собственно вопрос: Ускорит ли совместное использование FisrtOnly и FirstFast получение одной и только одной записи, если в результирующей выборке может быть несколько записей?

На "вскидку" не скажу. Надо экспериментировать. Однако практика показывает, что "родные" оптимизаторы SQL-сервера, как правило, справляются с задачей оптимизации (ускорения) выборки значительно лучше, чем "ручное" указание что и как надо делать. А хинт FisrtFast - это и есть "ручное" указание. Т.е., в общем случае, его использование, скорее всего, приведет не к ускорению, а к замедлению получения выборки.

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

[NetBus]

Ок. Спасибо все понятно, крайне признателен за исчерпывающую информацию. =))

[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 сессии

[mazzy]

См. также http://axapta.mazzy.ru/lib/indexhints/

Перенес в базу знаний.

2 AndyD
как же не даст?
- курсор на сервере закрывается быстрее = снятие блокировок, ускорение выборок для др пользователей
- сеть не напрягается, скачивая лишь 2 записи.

Средняя "отзывчивость" и скорострельность выше.

В любом др случае можно получить максимум лишь одно из этих преимуществ

[AndyD]

Извините, не понял к какой части моего сообщения относится реплика.

В обох случаях фразы "принципиального выигрыша в быстродействии не даст" и "ничего не даст" относится к совместному использованию хинтов firstonly и firstfast, т.е. имеет ли смысл добавлять еще один хинт, если нам требуется выбрать только одну запись.

именно. Даст улучшение при выборке 1 записи

[AndyD]

Т.е. вы хотите сказать, что select firstonly firstfast, увеличит производительность по сравнения с select firstonly?

для всех пользователей системы - да

[AndyD]

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

см выше

[AndyD]

Выше только звезды

Ладно, сделаю еще одну попытку.
И при выборке select firstonly firstfast и при select firstonly на клиента будет отфетчено 2 записи. Для MS-SQL отличие в хинте OPTION(FAST n), где n для первого случая = 1, для второго 2. Для Oracle различий нет. В обоих случаях уходит хинт /*+ FIRST_ROWS*/

Укажите, пожалуйста, в чем противоречие моим выводам?

перечитал.
firstFast , получается, никакого фаста не дает? Или все-таки Fast 1 ускоряет выборку 1 записи, замедляя выборку остальных?

firstOnly почему фетчит 2 записи?

(выброка != фетч)

[AndyD]

Все нижеследующее имеет отношение только к работе с MS SQL Server

Давайте сначала определимся, что делает FAST

Цитата:

SQL Server Books Online
Specifies that the query is optimized for fast retrieval of the first number_rows (a nonnegative integer). After the first number_rows are returned, the query continues execution and produces its full result set.

Если в запросе присутствует этот хинт, то при получении первых n записей сервер вернет их клиенту и после этого продолжит выполнять запрос до получения оставшихся. Вот и все. Никаких ускорений и никаких замедлений. Предназначение хинта - отзывчивость приложения, т.е. клиент получит первые записи с максимальной скоростью, а затем будет ждать получения оставшихся.

В чем заключается оптимизация? Рассмотрим на примере InventTable (планы выполнения - во вложении).

PHP код:

select recid from InventTable order by dataareaid, itemgroupid 


Что будет, если отослать этот запрос на сервер? Какой план запроса будет выбран?
Будет выбран кластерный индекс I_175ITEMIDX. Оптимизатор решил, что выбрать записи по нему, а затем отсортировать на сервере будет быстрее, чем использовать индекс по полям, учавствующим в сортировке. Но в этом случае для получения первой записи на клиенте необходимо получить все записи таблицы, отсортировать их и только после этого клиент получит то что запросил. При большом количестве записей ожидание выполнения запроса может занять десятки секунд.

PHP код:

select recid from InventTable order by dataareaid, itemgroupid option (fast 10) 


Добавим хинт FAST. Теперь план исполнения изменился. Используется индекс по полям, участвующим в предложении ORDER BY (I_175GROUPITEMIDX). Первые записи могут быть получены сразу. На клиента отправляется 10 записей, а затем сервер, так же как и в первом случае, продолжает поиск записей, удовлетворяющих условию. Первые записи могут быть получены сразу, но общее время выполнения запроса может увеличиться.

В общем виде использование хинта FAST ведет вот к чему. Если существует индекс по полям, входящим в предложение ORDER BY, то будет использоваться этот индекс и мы получим первые записи насколько возможно быстро. Если нет, то будет использоваться индекс выбранный оптимизатором, а сортировка будет произведена на сервере. Получение записей будем ждать, пока запрос не будет выполнен полностью.

Так как Axapta использует хинт FAST во всех запросах, то, получается, что ORDER BY является недокументированной возможностью повлиять на выполнение запроса (по крайней мере мне не встречалась информация по этому поводу). А так же возможностью затормозить выполнение запроса по самое не балуйся.


Перейдем к рассмотрению работы самой Axapta'ы с SQL сервером.

А работает она с использованием семейства функций sp_cursor* jtds.sourceforge.net/apiCursors.html. При выполнении любого запроса (в том числе и используемого в DataSource) Axapta открывает на сервере курсор (курсор имеет тип Fast forward-only cursor). При этом может использоваться подготовка (prepare) запроса для дальнейшего многократного использования. Каждая функция принимает в качестве параметров тип курсора, вид блокировки и сам запрос (или его хэндл для prepared запросов). Функция открывает курсор, отдает запрос серверу и ожидает его выполнения. После получения ответа от сервера клиенту возвращается хэндл курсора. Дальше Axapta начинает фетчить записи на клиента (sp_cursorfetch). Записи, в основном, фетчатся группами (для ускорения выборки). После окончания обработки происходит закрытие курсора (sp_cursorclose), а так же для prepared запросов возможен вызов sp_cursorunprepare если необходимость в нем отпала.
У этого семейства функций есть одна осбенность, которая помогает Axapta'е минимизировать простои при выполнении запросов - все они возвращают управление в тот момент, когда вернет управление сервер. Т.е. при использовании хинта FAST мы получим хэндл курсора сразу после получения первых записей (тут необходимо учитывать то, что написано выше про FAST, т.е. могут быть запросы, которые в любом случае будут выполнены полностью). Дальнейшее продолжение запроса выполняется при фетче записей, причем каждый раз возвращается столько, сколько нам необходимо.

Теперь вернемся к предмету разговора - совместному использованию firstonly и firstfast.
Само выполнение запроса не ведет к возврату записей на клиента, т.е. даже не смотря на то, что при использовании firstfast в запросе передается FAST 1, получим эти записи мы лишь при фетче - сервер выберет 1 уже уже найденную запись и продолжит поиск остальных записей группы. Т.е. реально время, потраченное на поиск и выборку записей будет и в том и в другом случае одинаковым.
Тут может возникнуть такое соображение - хорошо, но в случае открытия на обновление могут возникнуть блокировки и даже разница в одну запись может оказаться существенной. Но в данном случае Axapta ведет себя несколько иначе - при использовании хинта firstonly в запрос добавляется FAST 1, а на клиента фетчится 1 запись.

Таким образом добавление firstfast в запрос с firstonly ничего не добавляет в плане производительности.

Использование firstfast отдельно имеет смысл только при открытии запроса на обновление, т.к. в этом случае при большой нагрузке на сервер возможен временной интервал м-ду открытием запроса (с одной записью) и фетчем записей на клиента (группы записей)


2 moderators
Если это интересно, то я мог бы разместить более расширенную информацию по работе Axapta с сервером. Укажите в каком разделе. Приношу извинения, если этот вопрос надо было задавать не в этом сообщении

[kvan]

Цитата:

Если это интересно, то я мог бы разместить более расширенную информацию по работе Axapta с сервером.

Было бы очень интересно еще почитать об этом!

[leshy]

Цитата:
--------------------------------------------------------------------------------
Изначально опубликовано AndyD:
Если это интересно, то я мог бы разместить более расширенную информацию по работе Axapta с сервером

Если Вас не затруднит. Эта информация была бы очень полезна!

[George Nordic]

Да,да, просим - просим! Лучше публиковать сразу в "Полезные материалы".

Кстати, Сергей наверняка попросит оформить в виде статьи и разрешения разместить на своем сайте

С Уважением,
Георгий.