Проблемы с Exists Join

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

Что-то я группу событий Perfomance в профайлере MS SQL 2005 не нашел...

Reads - показывает вполне ожидаемые значения коррелирующиеся с уже озвученным выводом. Не так идет чтение, как ожидается. Даже самим MS SQL.

Exists: Duration = 2260 Reads = 480454
Inner: Duration = 21 Reads = 105

"Чудесный" способ не повлиял никак. Т.е. вообще. Разница в пределах погрешности. Duration на 1 миллисекунду изменился. Что, собственно, и следовало ожидать. Ведь речь идет не о парсинге на стороне Axapta, а о работе собственно сервера MS SQL. Ему-то какая разница в каком порядке расположены условия?

Насчет "плохо" выполнение по индексу - первый раз слышу. Я же привел цифру не времени выполнения, а стоимости этапа выполнения запроса. Поскольку основа запроса - это выборка по SalesLine - вполне естесственно, что стоимость именно этой операции будет самой высокой. Да, наверное стоит заметить, что у нас этот индекс сделан кластерным.

Насчет статистики могу сказать, что пока общее количество записей в таблице wmsBillOfLadingOrder несопоставимо меньше количества записей в SalesLine. Разница в несколько порядков.

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

[Wamr]

Цитата:

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

Что-то я группу событий Perfomance в профайлере MS SQL 2005 не нашел...

надо было галочку Show all events поставить

Цитата:

Насчет "плохо" выполнение по индексу - первый раз слышу. Я же привел цифру не времени выполнения, а стоимости этапа выполнения запроса. Поскольку основа запроса - это выборка по SalesLine - вполне естесственно, что стоимость именно этой операции будет самой высокой. Да, наверное стоит заметить, что у нас этот индекс сделан кластерным.

Насчет статистики могу сказать, что пока общее количество записей в таблице wmsBillOfLadingOrder несопоставимо меньше количества записей в SalesLine. Разница в несколько порядков.

плохо Index Scan вместо Index Seek, возможно это из-за кластерности, и может быть не страшно - не знаю
Будь я оптимизатором SQL-сервера, я бы предложил
1. поиск в wmsBillOfLadingOrder по индексу BOM (есть у вас такой?)
2. Собрать все уникальные значения inventTransRefId
3. поиск в индексе в SalesLineIdx всех записей, относящихся к полученному списку
4. получение данных для определенного списка записей SalesLine
5. Дальнейшая фильтрация

Видимо, из-за кластерности п3 и 4 у вас объединены

У вас запросы на сервер так и уходят со значениями или они параметризированы?