Показать сообщение отдельно
Старый 24.01.2019, 15:43   #9  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от axotnik88 Посмотреть сообщение
1. 150.
2.
SELECT SUM(T1.PHYSICALINVENT),
SUM(T1.RESERVPHYSICAL),
SUM(T1.RESERVORDERED),
SUM(T1.ONORDER),
SUM(T1.QUOTATIONISSUE),
SUM(T1.ARRIVED),
SUM(T1.ORDERED),
..
T2.INVENTSIZEID,
T2.INVENTSTYLEID,
T2.INVENTSITEID,
T2.INVENTLOCATIONID,
T2.INVENTBATCHID,
T2.INVENTSTATUSID
Ну я бы сказал что здесь план запроса как раз нормальный. Сначала отбирается из InventDim по статусу, потом подгружаются из кластерного индекса обычные поля, потом читается из inventSum записи по данной номнклатуре и джойнятся с выбраными записями из inventDim. Единственное что можно попытаться улучшить - построить индекс по inventDum по всем условиям запроса. (Но надо конечно смотреть- какие у вас там группы складской аналитики используются. Если у вас 20 разных групп с разными комбинациями аналитики, то на каждую группу своего индекса не построишь).

Еще как идея - я аналогичную ситуацию лечил с помощью Clustered Index View,предложенного Data Tuning Advisor. Только мне пришлось после строительства view добавлять еще и индекс дополнительный, потому что запрос, используемый в clustered view,приводил к заметным задержкам по inventSum.update(). Но в итоге - у меня время запроса который при списании номенклатуры проверяет уровень запасов в наличии, упало с 4 секунд где-то до 100ms.
За это сообщение автора поблагодарили: axotnik88 (1), Logger (3).