Оптимизация запросов к БД в коде

[raz]

Цитата:

Сообщение от fed

Может быть глобальное отключение хинтов (возможное и в трешке кстати), более эффективно чем ручное переупорядочивание полей в запросах ?

согласен, но кто поручится, что в анализаторе DAX не осталось еще каких "улучшающих" алгоритмов?

[fed]

Цитата:

Сообщение от raz

согласен, но кто поручится, что в анализаторе DAX не осталось еще каких "улучшающих" алгоритмов?

А кто гарантирует что эти алгоритмы можно заблокировать переставляя поля в условиях запроса ?

[raz]

2 fed
Ты имеешь ввиду это?

Цитата:

HINT_INDEX (1) – если параметр включен, будут работать операторы INDEX HINT из X ++ кода. Кроме того, при использовании FORCELITERALS имеет побочное действие – при использовании SELECT по одной таблице с условиями в части WHERE по индексированному полю использование этого индекса будет указано в запросе автоматически;

отсюда http://axapta.mazzy.ru/lib/indexhints/

PS. Посоветуй "идеальный" hints, я посмотрю запросы.

[AndyD]

По поводу подстановки хинтов ядром - Как работает индекс и кеш запросов?

[fed]

Цитата:

Сообщение от raz

2 fed
Ты имеешь ввиду это? отсюда http://axapta.mazzy.ru/lib/indexhints/

PS. Посоветуй "идеальный" hints, я посмотрю запросы.

Идеальный hints - это отключение всех hints кроме firstfast/firstonly. Если у тебя в БД со статистикой в порядке, MS SQL/Oracle подберет вполне себе хороший маршрут исполнения запроса. Кстати именно поэтому начиная с DAX4 по умолчанию хинты просто игнорируются. А в трешке, в зависимости от номера KR значения флажков в indexhints менялось, так что прямо счас универсального хинта не посоветую...
Да и кстати - разговор то не про хинты, а вообще о разнице между инженерным и знахарским подходом к решению проблем.

[Ace of Database]

У меня всегда хинты были выключены.
Трассировку своих запросов показывать не хочу по политическим причинам.
Вот что показывает трассировка запросов, которые привел raz:

для запроса №1:

PHP код:

 FROM INVENTTRANS A WHERE ((DATAAREAID=?) AND (((((INVENTTRANSID=?) AND (ITEMID=?)) AND (STATUSISSUE=?)) AND (DATESTATUS=?)) AND (STATUSRECEIPT=?))) OPTION(FAST 20) 


для запроса №2:

PHP код:

 FROM INVENTTRANS A WHERE ((DATAAREAID=?) AND (((((STATUSRECEIPT=?) AND (STATUSISSUE=?)) AND (ITEMID=?)) AND (DATESTATUS=?)) AND (INVENTTRANSID=?))) OPTION(FAST 20) 


Для эксперимента, я включил хинты. И они стали попадать в запрос - так же как у raz'а.

для запроса №1:

PHP код:

FROM INVENTTRANS A(INDEX(I_177STATUSITEMIDX))  WHERE ((DATAAREAID=?) AND (((((INVENTTRANSID=?) AND (ITEMID=?)) AND (STATUSISSUE=?)) AND (DATESTATUS=?)) AND (STATUSRECEIPT=?))) OPTION(FAST 20) 


для запроса №2:

PHP код:

FROM INVENTTRANS A(INDEX(I_177STATUSITEMIDX))  WHERE ((DATAAREAID=?) AND (((((STATUSRECEIPT=?) AND (STATUSISSUE=?)) AND (ITEMID=?)) AND (DATESTATUS=?)) AND (INVENTTRANSID=?))) OPTION(FAST 20) 


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

[raz]

Цитата:

Сообщение от fed

Да и кстати - разговор то не про хинты, а вообще о разнице между инженерным и знахарским подходом к решению проблем.

Согласен! Но когда после очередного обновления замечаешь, что вендор в очередной раз сделал всем "сюрприз", сразу вспоминаются "Хочу бубен!!!!!".

[fed]

Цитата:

Сообщение от Ace of Database

У меня всегда хинты были выключены.
Трассировку своих запросов показывать не хочу по политическим причинам.
Вот что показывает трассировка запросов, которые привел raz:

Для эксперимента, я включил хинты. И они стали попадать в запрос - так же как у raz'а.

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

Тогда надо вынимать планы запросов из самого MS SQL и сравнивать по обоим вариантам. Советую почитать в BOL про dynamic views sys.dm_exec_query_stats, sys.dm_exec_sql_text и sys.dm_exec_query_plan.
Коротко говоря - есть возможность вытащить из MS SQLного кэша запросов текст и план исполнения некоторого количества запросов которые недавно исполнялись. По плану запроса можно будет понять что изменилось и попытаться построить теории - почему изменилось...

[sukhanchik]

Цитата:

Сообщение от Ace of Database

У меня всегда хинты были выключены.

На 4.0 (хинты отключены в конфиг утилите АОСа) джоб raz-а не вставил никаких указаний по индексам в планы запроса. Вывод - DAX не посчитала себя умнее SQL Server (SQL Server 2005 SP3)

[Ace of Database]

Цитата:

Сообщение от sukhanchik

На 4.0 (хинты отключены в конфиг утилите АОСа) джоб raz-а не вставил никаких указаний по индексам в планы запроса. Вывод - DAX не посчитала себя умнее SQL Server (SQL Server 2005 SP3)

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

[Wamr]

Ace of Database
можешь показать скриншот настройки РАБОЧЕГО АОСа
закладка Database (там нет серверов-баз-паролей) ?

[Ace of Database]

Цитата:

Сообщение от Wamr

Ace of Database
можешь показать скриншот настройки РАБОЧЕГО АОСа
закладка Database (там нет серверов-баз-паролей) ?

Вот картинка

[S.Kuskov]

Цитата:

Сообщение от Ace of Database

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

Цитата:

Сообщение от raz

Вероятнее всего проблема с изменением порядка полей и последующим ускорением/замедлением запросов лежит в плоскости оптимизатора аксапты, а не sql. В dax3 с какого-то kr оптимизатор аксапты начал сам подставлят индексы в запросы согласно условиям where.

Задумайтесь. Приведённая стратегия оптимизации если и будет действовать, то только в случае отсутствия подходящего индекса Т.е. если SQL Server (или возможно сама аксапта) выберет план запроса, в котором будет использоваться индекс, все условия будут обработаны в том порядке, в котором поля перечислены в индексе (а иначе нельзя, так устроен механизм индексирования). И здаётся мне, на выбор используемого индекса порядок следования условий в WHERE не влияет (можно проверить, но я почти уверен). Следовательно, вообще говорить о влиянии последовательности условий в WHERE на производительность можно только для запросов без индексов! (ну или о той части запроса, которая работает уже после первичной фильтрации по индексу. Но, согласитесь, что оптимизация на этом этапе уже несущественна)

[Wamr]

Ace of db, спасибо за скрин.
Еще одна просьба. Ты же перед тем как исправлять этот запрос вышел на него, наверное, через логирование длинных запросов, может там еще в истории остался старый вариант?
Если не можешь сразу сюда кинуть, то перешли на почту.

[Ace of Database]

Цитата:

Сообщение от Wamr

Ace of db, спасибо за скрин.
Еще одна просьба. Ты же перед тем как исправлять этот запрос вышел на него, наверное, через логирование длинных запросов, может там еще в истории остался старый вариант?
Если не можешь сразу сюда кинуть, то перешли на почту.

Я вышел на него потому, что накатили новую доработку, и мне ночью стали звонить, что закупки невозможно открыть - форма висит. Я приблизительно знал, где в отладчике смотреть, хотя доработка не моя была. То есть, я вышел на это место через отладчик, у меня на это ушла 1 минута.
И еще - запрос стал тормозить не сразу, а примерно через пару дней после накатки, то есть, возможно что и с индексами что-то было.

И сам запрос не очень долго висел - секунду или две. Просто, в закупке много строк.

PS. Я не знал, что тема вызовет такой ажиотаж. Знал бы - не писал. Ребята, пожалуйста давайте закроем тему.

[Ace of Database]

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

[Wamr]

задал вопрос - получи ответ
твоё исходное сообщение звучит со стороны примерно так:
"ставьте условия в where в соответствии с индексом - и будет счастье (MS превзойдет Oracle)"
естественно, всех удивило такое простое решение, которое никому в голову не приходило, и ни с теоретической ни практической точек зрения основания не имело.
Дальше была попытка выяснить в каких же условиях чудо-средство помогает, но добиться от тебя какого-то содействия не удается.

[Ace of Database]

Цитата:

Сообщение от Wamr

задал вопрос - получи ответ
твоё исходное сообщение звучит со стороны примерно так:
"ставьте условия в where в соответствии с индексом - и будет счастье (MS превзойдет Oracle)"
естественно, всех удивило такое простое решение, которое никому в голову не приходило, и ни с теоретической ни практической точек зрения основания не имело.
Дальше была попытка выяснить в каких же условиях чудо-средство помогает, но добиться от тебя какого-то содействия не удается.

Вы меня неправильно истолковали. В одном из сообщений в этой теме я писал, что ни в коем случае не утверждаю, что MS SQL лучше, чем Oracle. Просто, на MS SQL тоже можно работать.

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