AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: База знаний и проекты
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.09.2005, 16:54   #1  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
может логичнее select firstOnly firstFast, вместо select firstOnly
Часто в коде встречается, имеется в виду стандартный функционал без местных модификаций
PHP код:
select firstOnly ... <Table
что подразумевает, что из таблицы мы хотим получить ТОЛЬКО первую запись, и как при любом запросе, чем быстрее, тем лучше.
Возникает логичный вопрос, а почему не используется запись вида, —
PHP код:
select firstOnly firstFast ... <Table
ведь в этом случае первая запись должна появиться быстрее, чем в случае указанном немного выше. Поправте меня, если я не прав.
Старый 14.09.2005, 17:25   #2  
DenNik is offline
DenNik
Участник
 
62 / 9 (1) +
Регистрация: 24.05.2005
Re: может логичнее select firstOnly firstFast, вместо select firstOnly
Цитата:
Изначально опубликовано NetBus
PHP код:
select firstOnly ... <Table
...хотим получить ТОЛЬКО первую запись, ...


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

Изначально опубликовано NetBus
PHP код:
select firstOnly firstFast ... <Table
ведь в этом случае первая запись должна появиться быстрее...
Первая запись появится быстрее, только в случае если запрос возваращает несколко записей
Старый 14.09.2005, 17:39   #3  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Для MS SQL эти хинты преобразуются в OPTION(FAST n). По скорости примерно одинаково.
__________________
Axapta v.3.0 sp5 kr2
Старый 15.09.2005, 10:22   #4  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,701 / 1195 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Из книги: AXAPTA 3.0 Разработка бизнес-приложений. Алексей Еременко, Руслан Шашков

стр 368

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

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

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

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

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

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

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

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

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

Кроме того, не вполне ясно, в какой именно момент FirstOnly сделает выбор единственной записи. При получении первой записи или после получения всех записей. Тоже надо бы проверить...
За это сообщение автора поблагодарили: Recoilme (3).
Старый 15.09.2005, 10:38   #5  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Ок. Спасибо все понятно, крайне признателен за исчерпывающую информацию. =))
Старый 15.09.2005, 13:17   #6  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
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 сессии
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: alex55 (1).
Старый 15.09.2005, 16:56   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
См. также http://axapta.mazzy.ru/lib/indexhints/

Перенес в базу знаний.
__________________
полезное на axForum, github, vk, coub.
Старый 15.09.2005, 18:51   #8  
sassas
Гость
 
n/a
2 AndyD
как же не даст?
- курсор на сервере закрывается быстрее = снятие блокировок, ускорение выборок для др пользователей
- сеть не напрягается, скачивая лишь 2 записи.

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

В любом др случае можно получить максимум лишь одно из этих преимуществ
Старый 15.09.2005, 19:18   #9  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Извините, не понял к какой части моего сообщения относится реплика.

В обох случаях фразы "принципиального выигрыша в быстродействии не даст" и "ничего не даст" относится к совместному использованию хинтов firstonly и firstfast, т.е. имеет ли смысл добавлять еще один хинт, если нам требуется выбрать только одну запись.
__________________
Axapta v.3.0 sp5 kr2
Старый 16.09.2005, 15:39   #10  
sassas
Гость
 
n/a
именно. Даст улучшение при выборке 1 записи
Старый 16.09.2005, 15:50   #11  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Т.е. вы хотите сказать, что select firstonly firstfast, увеличит производительность по сравнения с select firstonly?
__________________
Axapta v.3.0 sp5 kr2
Старый 16.09.2005, 16:55   #12  
sassas
Гость
 
n/a
для всех пользователей системы - да
Старый 16.09.2005, 17:02   #13  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Скажите пожалуйста, на основании каких данных вы сделали такой вывод? По крайней мере приведенные мной говорят об обратном.
__________________
Axapta v.3.0 sp5 kr2
Старый 16.09.2005, 17:13   #14  
sassas
Гость
 
n/a
см выше
Старый 16.09.2005, 17:26   #15  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Выше только звезды

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

Укажите, пожалуйста, в чем противоречие моим выводам?
__________________
Axapta v.3.0 sp5 kr2
Старый 16.09.2005, 17:45   #16  
sassas
Гость
 
n/a
перечитал.
firstFast , получается, никакого фаста не дает? Или все-таки Fast 1 ускоряет выборку 1 записи, замедляя выборку остальных?

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

(выброка != фетч)
Старый 18.09.2005, 22:51   #17  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Все нижеследующее имеет отношение только к работе с 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 dataareaiditemgroupid 
Что будет, если отослать этот запрос на сервер? Какой план запроса будет выбран?
Будет выбран кластерный индекс I_175ITEMIDX. Оптимизатор решил, что выбрать записи по нему, а затем отсортировать на сервере будет быстрее, чем использовать индекс по полям, учавствующим в сортировке. Но в этом случае для получения первой записи на клиенте необходимо получить все записи таблицы, отсортировать их и только после этого клиент получит то что запросил. При большом количестве записей ожидание выполнения запроса может занять десятки секунд.
PHP код:
select recid from InventTable order by dataareaiditemgroupid 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 с сервером. Укажите в каком разделе. Приношу извинения, если этот вопрос надо было задавать не в этом сообщении
Миниатюры
Нажмите на изображение для увеличения
Название: inventtableplans.jpg
Просмотров: 596
Размер:	66.5 Кб
ID:	710  
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: Garic (1), blokva (1), Recoilme (3), Logger (7), wojzeh (1).
Старый 19.09.2005, 11:47   #18  
kvan is offline
kvan
Moderator
Аватар для kvan
Дети Юза
 
775 / 49 (3) +
Регистрация: 07.08.2002
Адрес: Donetsk
Цитата:
Если это интересно, то я мог бы разместить более расширенную информацию по работе Axapta с сервером.
Было бы очень интересно еще почитать об этом!
Старый 19.09.2005, 11:53   #19  
leshy is offline
leshy
Участник
 
118 / 11 (1) +
Регистрация: 23.02.2004
Адрес: Киев
Цитата:
--------------------------------------------------------------------------------
Изначально опубликовано AndyD:
Если это интересно, то я мог бы разместить более расширенную информацию по работе Axapta с сервером

Если Вас не затруднит. Эта информация была бы очень полезна!
Старый 19.09.2005, 12:05   #20  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Да,да, просим - просим! Лучше публиковать сразу в "Полезные материалы".

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

С Уважением,
Георгий.
Теги
axapta, firstfast, firstonly, hint, запрос (query), как правильно, полезное, производительность

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
знатокам select Nikolaich DAX: Программирование 9 29.11.2006 08:49
Fred Shen: Always use recId to know if a select statement returns a record Blog bot DAX Blogs 0 28.10.2006 16:40
Вопрос про Demand Planner slava09 DAX: Функционал 4 25.09.2006 11:43
Переменная в select Goldy DAX: Программирование 21 12.05.2006 13:46
While Select .. ? slava DAX: Программирование 7 17.01.2002 13:08

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:21.