Поле DataAreaID в индексах SQL Server

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

Цитата:

-- Вопрос: почему не используется индекс ECC_FinDimIdx?

Почему не работает подсказка оптимизатору - не знаю. Может, физически нет такого индекса. Судя по префиксу - это какая-то кастомизация. Хотя для Axapta использование подсказок оптимизатору - порочная практика, которая не уменьшает, а увеличивает количество проблем.

Кроме того, при оптимизации запросов следует учитывать тот факт, что Axapta обращается к данным SQL не прямыми запросами, а через "обертку" в виде курсоров.

exec sp_cursoropen
exec sp_cursorfetch
exec sp_cursorclose

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

Проблемы с Exists Join

Вкратце, попробуйте заменить Exists на Inner Join. Поскольку у Вас связь InventSum и InventDim, то в данном случае - это будет корректная замена. И уберите подсказку оптимизатору для индекса

[gkochkin]

Цитата:

Сообщение от Владимир Максимов

Почему не работает подсказка оптимизатору - не знаю. Может, физически нет такого индекса. Судя по префиксу - это какая-то кастомизация. Хотя для Axapta использование подсказок оптимизатору - порочная практика, которая не уменьшает, а увеличивает количество проблем.

Кроме того, при оптимизации запросов следует учитывать тот факт, что Axapta обращается к данным SQL не прямыми запросами, а через "обертку" в виде курсоров.

exec sp_cursoropen
exec sp_cursorfetch
exec sp_cursorclose

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

Проблемы с Exists Join

Вкратце, попробуйте заменить Exists на Inner Join. Поскольку у Вас связь InventSum и InventDim, то в данном случае - это будет корректная замена. И уберите подсказку оптимизатору для индекса

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

[trud]

Цитата:

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

в этом случае статистика показывает меньшее кол-во логических чтений и процессорного времени.
На тестовой системе я все это сделал, но в продакшн это не хотят пускать, прикрываясь тем, что поле DataAreaID определяет рамки компании и всегда ставится аксаптой на первое место.

если планы одинаковые, то порядок то тут не причем. просто ваш результирующий индекс по видимому имеет другой Fill factor(т.е. получается страницы расположены более плотно раз кол-во логических чтений меньше - тут я подразумеваю что дефрагментацию вы выполнили перед тестом).
Это все приведет к увеличению кол-ва расщеплений этих страниц при обновлении-вставке данных(а для InventSum это критично), что в конечном итоге потенциально замедлит всю систему. так что вполне аргументировано не дают переносить

[gkochkin]

Цитата:

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

если планы одинаковые, то порядок то тут не причем. просто ваш результирующий индекс по видимому имеет другой Fill factor(т.е. получается страницы расположены более плотно раз кол-во логических чтений меньше - тут я подразумеваю что дефрагментацию вы выполнили перед тестом).
Это все приведет к увеличению кол-ва расщеплений этих страниц при обновлении-вставке данных(а для InventSum это критично), что в конечном итоге потенциально замедлит всю систему. так что вполне аргументировано не дают переносить

Планы не одинаковые. План просто при выполнении запроса не использует нами добавленный индексI_698ECC_FINDIMIDX.
С хинтом соответственно использует.
Если поле DataAreaID перенести в конец - оптимизатор хватает наш индекс I_698ECC_FINDIMIDX и количество чтений (и процессорное время) значительно меньше, чем без использования этого индекса (I_698ECC_FINDIMIDX).

[trud]

Цитата:

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

С хинтом соответственно использует.

А в индексе что за поля? все 5 полей запроса из InventDim?
просто на практике я видел ситуации когда создание подобных индексов приводило к остановкам системы, из за того, что собственно для ряда значений поиск остатков через InventDim приводил к полному скану этой таблицы.
т.е. надо проверить что не используются всякие обобщенные партии и гтд

[gkochkin]

Цитата:

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

А в индексе что за поля? все 5 полей запроса из InventDim?
просто на практике я видел ситуации когда создание подобных индексов приводило к остановкам системы, из за того, что собственно для ряда значений поиск остатков через InventDim приводил к полному скану этой таблицы.
т.е. надо проверить что не используются всякие обобщенные партии и гтд

dataareaid
inventdimid
inventsizeid
inventcolorid
inventlocationid
inventbatchid
inventgtdid_ru

[trud]

О..
этот индекс и не должен использоваться. т.е. какой у вас план то - найти сначала номенклатуру(из InventSum) и InventDimId, а потом проверить все комбинации аналитик? для проверки комбинаций SQL считает что лучше использовать кластерный индекс по InventDimId.
тут можно попробовать создать вот такой(ниже) - искать сразу InventDim и потом по нему уже InventSum, но опять же надо смотреть на ваши данные, т.е. это будет работать если нет обобщенных партий-гтд и нет других аналитик
dataareaid
inventsizeid
inventcolorid
inventlocationid
inventbatchid
inventgtdid_ru