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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.05.2008, 10:29   #1  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Изменение плана запроса при увеличении выборки
Есть таблица в которой много записей (17 млн). В ней есть поле SalesDate типа дата и по этому полю есть индекс. Выполняется SQL-запрос:
X++:
SELECT * FROM TABLE
WHERE SALESDATE >=
Если значение дата отличается от сегодняшней более чем на неделю, то план запроса показывает, что идет fullscan по таблице, если нет, то происходит выборка по индексу.

С чем может быть связано такое поведение? Реиндексация и обновление статистики не помогает.
Старый 07.05.2008, 10:49   #2  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,685 / 1189 (43) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Что значит "с чем"? Сам же и ответил - отличается больше чем на неделю.

Оптимизатор сервера пришел к выводу, что получить эту выборку будет быстрее, если сканировать не индекс, а саму таблицу. Ведь в данном случае "оптимизация" - означает "ускорение". Использование индекса - далеко не всегда приводит именно к "ускорению".
Старый 07.05.2008, 11:01   #3  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Что значит "с чем"? Сам же и ответил - отличается больше чем на неделю.

Оптимизатор сервера пришел к выводу, что получить эту выборку будет быстрее, если сканировать не индекс, а саму таблицу. Ведь в данном случае "оптимизация" - означает "ускорение". Использование индекса - далеко не всегда приводит именно к "ускорению".
В том-то и дело, что это приводит к конкретному замедлению. Если указать в запросе индекс явно
X++:
SELECT * FROM TABLE(INDEX( ))
WHERE SALESDATE >=
то запрос выполняется за минуту (при любом значении даты), если не указывать, то несколько часов. Так как указать индекс явно из аксапты не получается (по крайне мере я не знаю как это сделать через Query), то и приходится думать почему оптимизатор принимает решение, приводящее не к ускорению, а к замедлению и как его заставить этого не делать.
Старый 07.05.2008, 11:29   #4  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Кусок кода из метода \\Classes\\InventDimCtrl_Frm_OnHand\modifyQuery:

X++:
        qbsDim.addSortIndex(indexnum(InventDim,DimIdIdx));
        qbsDim.indexIsHint(true);
Старый 07.05.2008, 11:45   #5  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Кусок кода из метода \\Classes\\InventDimCtrl_Frm_OnHand\modifyQuery:

X++:
        qbsDim.addSortIndex(indexnum(InventDim,DimIdIdx));
        qbsDim.indexIsHint(true);
По-моему это немного не то.
addSortIndex указывает, что нужно использовать индекс при выполнении сортировки (добавляет USING INDEX DimIdIdx) в секцию ORDER BY запроса, а нужно чтобы нужный индекс использовался при выборке данных
Старый 07.05.2008, 11:47   #6  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Для этого там и указана еще вторая строка - indexIsHint

Если бы ее не было, то индекс использовался бы для сортировки
Если она есть, это дает указание системе использовать этот индекс при выборке данных.

Проверьте. Должно помочь
Старый 07.05.2008, 11:59   #7  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,295 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Хм. Прикольно. Редкий случай, когда указание индекса не просто оправдано, но необходимо.

Оптимизатор тоже прав. У него куча запросов по последнему дню. Есть кластерный индекс по SalesId, так как SalesID постоянно растёт, т.е. растёт вместе с датой. Отсюда и вывод оптимизатора - зачем нужен индекс, если результат без индекса такой же, что с индексом, но быстрее. Очень интересный случай Вопрос, как оптимизатор определил, что в старых записях не поменялись даты. Видимо, кеширует старые результаты. Но здесь надо спецов по СУБД MS SQL теребить.
__________________
Михаил Андреев
https://www.amand.ru
Старый 07.05.2008, 11:56   #8  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Может быть теоретически это и так, но практически получается, что к запросу в аксапте добавляется INDEXISHINT после SELECT и USING INDEX в ORDER BY, но на сервер уходит такой же запрос, что и без указания этих параметров, следовательно план запроса не изменяется.
Старый 07.05.2008, 12:02   #9  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,295 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Может быть теоретически это и так, но практически получается, что к запросу в аксапте добавляется INDEXISHINT после SELECT и USING INDEX в ORDER BY, но на сервер уходит такой же запрос, что и без указания этих параметров, следовательно план запроса не изменяется.
Странно, недавно проверял запросы, связанные с выборкой по складских аналитикам. План запроса явно меняется при изменении хинтов и время выборки тоже. Более того, оптимизировать запросы в этой части логистики вообще было бы невозможно во многих случаях работы с логистикой.
__________________
Михаил Андреев
https://www.amand.ru
Старый 07.05.2008, 12:26   #10  
Alexei S is offline
Alexei S
Участник
 
21 / 14 (1) ++
Регистрация: 15.12.2006
Адрес: Новосибирск
Lucky13, а какой SQL Server используете?
Старый 07.05.2008, 12:36   #11  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Оптимизатор смотрит на статистику (вы ее давно перестраивали)

В книжке про оракл упоминалось правило 5 процентов - если индекс позволяет выбрать 5% записей, то он используется иначе - нет (давно было могу чо-то наврать)
Старый 07.05.2008, 13:01   #12  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от Alexei S Посмотреть сообщение
Lucky13, а какой SQL Server используете?
MS SQL 2005
Цитата:
Сообщение от belugin Посмотреть сообщение
Оптимизатор смотрит на статистику (вы ее давно перестраивали)

В книжке про оракл упоминалось правило 5 процентов - если индекс позволяет выбрать 5% записей, то он используется иначе - нет (давно было могу чо-то наврать)
Статистика обновлялась перед тем как выполнить запрос. Есть критичная дата после которой индекс перестает использоваться, в данном случае это 10 дней. Т.е.
За 10 дней - результат 595 записей, поиск по индексу
За 11 дней - результат 637 записей, поиск не по индексу

При общем количестве записей 17 млн и то и другое явно меньше 5%
Старый 07.05.2008, 13:05   #13  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от Lucky13
...
За 10 дней - результат 595 записей, поиск по индексу
За 11 дней - результат 637 записей, поиск не по индексу
...
Это по факту или по оценкам оптимизатора?

Оценки оптимизатора более-менее соответствуют реальности?
__________________
С уважением,
glibs®
Старый 07.05.2008, 13:21   #14  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от glibs Посмотреть сообщение
Это по факту или по оценкам оптимизатора?

Оценки оптимизатора более-менее соответствуют реальности?
Это по факту. А что значит по оценкам оптимизатора, где эти оценки можно посмотреть?
Старый 12.05.2008, 16:22   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,928 / 3227 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от belugin Посмотреть сообщение
Оптимизатор смотрит на статистику (вы ее давно перестраивали)

В книжке про оракл упоминалось правило 5 процентов - если индекс позволяет выбрать 5% записей, то он используется иначе - нет (давно было могу чо-то наврать)
Если не ошибаюсь, там можно настроить БД самому на какой угодно процент.
Старый 07.05.2008, 13:07   #16  
ivas is offline
ivas
Участник
Аватар для ivas
 
252 / 68 (3) ++++
Регистрация: 22.12.2005
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
С чем может быть связано такое поведение? Реиндексация и обновление статистики не помогает.
а какой кластерный индекс на вашей таблице?
__________________
aLL woRk aNd nO JoY MAKes jAck a dULL Boy
Старый 07.05.2008, 13:24   #17  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от ivas Посмотреть сообщение
а какой кластерный индекс на вашей таблице?
Кластерных индексов на таблице нет есть некластерный по полям SALESDATE и SALESTIME. Поле SALESDATE первое в индексе
Старый 07.05.2008, 14:10   #18  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,731 / 406 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Кластерных индексов на таблице нет есть некластерный по полям SALESDATE и SALESTIME. Поле SALESDATE первое в индексе
может лучше создать отдельный индекс только по полю SALESDATE?
Старый 07.05.2008, 14:55   #19  
Alexei S is offline
Alexei S
Участник
 
21 / 14 (1) ++
Регистрация: 15.12.2006
Адрес: Новосибирск
Версия из категории "Мозговой штурм"
Видимо, SQL Server, рассчитывая объем данных, который потребуется загрузить для обработки запроса, считает, что меньшим будет объем записей во всей таблице нежели страницы индекса + соответствующие им записи таблицы. Тогда возможным решением будет то, что предложил ice - это сократит размер записей индекса:
Цитата:
Сообщение от ice Посмотреть сообщение
может лучше создать отдельный индекс только по полю SALESDATE?
Старый 07.05.2008, 15:30   #20  
Lucky13 is offline
Lucky13
Участник
1C
 
714 / 198 (8) ++++++
Регистрация: 21.10.2004
Цитата:
Сообщение от Alexei S Посмотреть сообщение
Видимо, SQL Server, рассчитывая объем данных, который потребуется загрузить для обработки запроса, считает, что меньшим будет объем записей во всей таблице нежели страницы индекса + соответствующие им записи таблицы. Тогда возможным решением будет то, что предложил ice - это сократит размер записей индекса:
Не помогло. Похоже в данном случае оптимизатор даже не пытается подобрать индекс
Теги
план запроса, производительность, статистика, запрос (query), индекс

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Подготовка запроса(ламерские вопросы продолжаются) HorrR DAX: Программирование 4 08.07.2008 13:23
Изменить план выполнения запроса Sequel DAX: Администрирование 2 29.05.2008 15:46
Изменение query запроса в локальных настройках пользователя? 3oppo DAX: Программирование 16 09.04.2008 11:15
Оптимизация запроса oleg_e DAX: Программирование 16 11.01.2008 10:22
Ускорение выполнения запроса Oracle + MS Axapta Горбунов Дмитрий DAX: Программирование 17 15.11.2005 18:13

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:17.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.