AX2012: После прочтения документа по изменениям в inventTrans, борюсь с непреодолимым желанием уйти в запой на недельку

[AndyD]

Цитата:

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

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

Ну, чтение из файла - это же не весь цикл получения данных по запросу.
При большом размере записи будет за один раз меньше кол-во переданных на клиент данных
Простой запрос select * from InventTable на моих данные в два с половиной - три раза медленнее, чем select itemId from InventTable

[Alexius]

Цитата:

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

Простой запрос select * from InventTable на моих данные в два с половиной - три раза медленнее, чем select itemId from InventTable

Бесспорно, т.к. во втором случае серверу БД нет необходимо читать данные из всей таблицы с кучей полей, а достаточно воспользоваться одним из некластерных индексов содержащих ItemId (GroupItemIdx, TypeIdx, DimGroupItemIdx, и т.д.)

[AndyD]

Цитата:

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

Бесспорно, т.к. во втором случае серверу БД нет необходимо читать данные из всей таблицы с кучей полей, а достаточно воспользоваться одним из некластерных индексов содержащих ItemId (GroupItemIdx, TypeIdx, DimGroupItemIdx, и т.д.)

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

[fed]

Цитата:

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

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

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

[Alexius]

2 AndyD
На сколько я понял, структура данных АХ 2012, описанная в Implementing_InventTrans_refactoring_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf не соответствует действительности.

[Alexius]

Цитата:

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

Не понятно, почему именно некластеным?

Т.к. при использовании некластерного индекса для получения результата перебирается меньше данных.

Цитата:

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

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

Т.е. план выполнения запросов на MS SQL одинаковый для обоих запросов ?

SELECT * FROM INVENTTABLE

SELECT ItemId FROM INVENTTABLE

[AndyD]

Цитата:

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

Т.к. при использовании некластерного индекса для получения результата перебирается меньше данных.Т.е. план выполнения запросов на MS SQL одинаковый для обоих запросов ?

SELECT * FROM INVENTTABLE

SELECT ItemId FROM INVENTTABLE

Вы правы, индексы в данном случае разные.

Но переделка запроса на поле, не участвующее ни в одном индексе картину не поменяло - скорость различается на те же 2,5-3 раза

[Alexius]

Цитата:

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

Но переделка запроса на поле, не участвующее ни в одном индексе картину не поменяло - скорость различается на те же 2,5-3 раза

Занятно, я ожидал уменьшения разницы. Видимо действительно в этом примере так велики затраты на формирования набора записей со всеми полями и возвращение его клиенту (АОСу). В любом случае запросы с избыточным числом полей ЗЛО