Тормоза SQL при наличии в InventDimId русских букв.

[polygris]

Заметил интересную особенность SQL 2005 (Axapta 3.0 SP5 KR2).
Все номерные серии в Аксе у меня начинаются с русских букв (пример: НА99999 - InventDimId)
Так вот при joine к таблицам InventSum, InventTrans (запрос на T-SQL) происодят жуткие тормоза (загруз SQL на 8 процессорной тачке под 100%). Если в запросе в условии join TRIM первые руссие символы - запрос выполняется несколько секунд при слабой загрузке проца.
1-й вопрос: Используете ли вы в номерных сериях документов в Аксе русские буквы.
2-й вопрос: Может ли эта ситуация реально влиять на производительность выполнения запросов.

[belugin]

Я бы посмотрел план запроса - может со статистикой чего?
А SP какие-нибудь на SQL накатаны?

[polygris]

Статистику перед этим пересчитывал.
Да канечно все последний апдейты SP2

[mazzy]

Цитата:

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

Заметил интересную особенность SQL 2005 (Axapta 3.0 SP5 KR2).
Все номерные серии в Аксе у меня начинаются с русских букв (пример: НА99999 - InventDimId)
Так вот при joine к таблицам InventSum, InventTrans (запрос на T-SQL) происодят жуткие тормоза (загруз SQL на 8 процессорной тачке под 100%). Если в запросе в условии join TRIM первые руссие символы - запрос выполняется несколько секунд при слабой загрузке проца.
1-й вопрос: Используете ли вы в номерных сериях документов в Аксе русские буквы.
2-й вопрос: Может ли эта ситуация реально влиять на производительность выполнения запросов.

1. а какой collation установлен на SQL?
2. Для служебных идентификаторов лучше использовать не #, а спецсимвол &. Код получается компактнее.
http://axapta.mazzy.ru/lib/numbersequenceformat/

[polygris]

Collation: Cyrillic_General_CI_AS

[mazzy]

тогда вряд ли из-за него.
смотрите в профайлер и в план запроса.

[polygris]

Результаты расследования проблемы.
Первое, что сделали это в InventDim в поле InventDimId заменили (с помощьюе renamePrimaryKey()) первые две русские буквы нулями (запрос без трима начал работать и отработал за 30 сек. С тримом - отработал за 10 секунд (т.е. как и раньше, в принципе другого и не могло и быть)
Второе, что сделали это обрезали InventDimId в InventDim до трех цифр (опятьже с помощью renamePrimaryKey()). Результат запрос без тримов выполняется 3 секунды.
Т.е. можно сделать вывод о том чем меньше размер ключа в InventDimId, тем шустрей работает JOIN по этому полю.

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

Тебе уже намекнули, посмотри план выполнения этого запроса собственно на сервере. В MS SQL. И не мучь животинку (AXAPTA) разными настройками пока не поймешь причину тормоза.

Если бы ты с этого начал, то мог бы заметить, что от размера поля скорость завист слабо. Она зависит от используемых индексов. Если работает TRIM(), то индекс использовать нельзя. Вынужденно сканируем таблицу. Отсюда и тормоз.

[polygris]

Цитата:

Если бы ты с этого начал, то мог бы заметить, что от размера поля скорость завист слабо. Она зависит от используемых индексов. Если работает TRIM(), то индекс использовать нельзя. Вынужденно сканируем таблицу. Отсюда и тормоз

План канечно же смотрел.
Тогда получается при моем размере таблици InventDim скан работает быстрее чем прыжок по индексу.

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

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