Проблемы с Exists Join

[Wamr]

((B.SalesId=right(space(20)+'827137',20)) AND (B.SalesId=A.SALESID))

Я бы сделал ставку вот на это

Данные то у меня другие, так что и планы могут у нас быть разными.

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

Планы выполнения запросов

SELECT A.ITEMID,A.SALESQTY,A.LINEAMOUNT,A.SALESID,A.RECID 
FROM SALESLINE A 
WHERE ((A.DATAAREAID='цтр') 
	AND (A.SALESQTY<>0)) 
	AND EXISTS (SELECT 'x' FROM WMSBILLOFLADINGORDER B 
		WHERE ((B.DATAAREAID='цтр') 
			AND ((B.INVENTTRANSREFID=A.SALESID) 
			AND (B.BILLOFLADINGID='101'))))

SELECT A.ITEMID,A.SALESQTY,A.LINEAMOUNT,A.SALESID,A.RECID 
FROM SALESLINE A,WMSBILLOFLADINGORDER B 
WHERE ((A.DATAAREAID='цтр') 
	AND (A.SALESQTY<>0)) 
	AND ((B.DATAAREAID='цтр') 
	AND ((B.INVENTTRANSREFID=A.SALESID) 
	AND (B.BILLOFLADINGID='101')))

То же самое, но "обернутое" в курсоры



Лично мне кажется, что использования хинтов - это порочная практика. Как правило, даже если удается оптимизировать запрос, то с течением времени, с изменением объема таблицы и статистики ее использования, хинты начинают не ускорять, а замедлять работу запроса.

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

Вставка во временную таблицу при работе курсоров - это настолько незначительная задержка, что не стоит обращать на нее внимание. Посмотри прилагаемые планы исполнения. При работе через Exists вставка в курсор стоит 0%, а при раьоте через Inner - 35%. Тем не менее, общая стоимость запроса с Exists составляет 100% по сравнению с 0% стоиомости запроса с Inner.

[vanokh]

Цитата:

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

Лично мне кажется, что использования хинтов - это порочная практика...

Насчет хинтов согласен - порочная, я использовал хинт, только чтобы проверить гипотезу о перемене мест "слагаемых"

Цитата:

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

Вставка во временную таблицу при работе курсоров - это настолько незначительная задержка, что не стоит обращать на нее внимание...

Да, временные таблицы в данном случае несущественная задержка.


А теперь по существу Мне удалось воспроизвести ваш случай с использованием других таблиц - SalesTable (100 тыс.) и RContractTable (10 тыс.). Также как и у вас - просто запросы выполняются быстро, в курсорах exists жутко тормозит (стоимость запроса 99%). И мне кажется я нашел причину

Чем отличаются курсоры от простых запросов? Тем, что запросы возвращают сразу все записи, а в курсорах записи выбираются по одной путем FETCH. Логично предположить, что оптимизатор строит план запроса для курсора с учетом этой особенности - быстрая выборка одной записи.

Гипотеза подтвердилась - если курсор сделать STATIC (с хранением всех выбранных результатов в tempdb) или FAST_FORWARD (с оптимизацией), то план построится более оптимальный и тормозить не будет (затраты 50/50). Попробуйте у себя.

Остается вопрос - использует ли Ax такие курсоры?...

Дополнение - курсор по умолчанию создается с возможностью редактирования, если поставить READ_ONLY, тоже будет быстро (все результаты так же выбираются сразу и хранятся в tempdb)

[Wamr]

Господа, что-то мы топчемся на месте. Есть ещё какие-нибудь идеи куда копать в поисках такого странного поведения оптимизатора?

[Wamr]

Владимир Максимов,
скажите, пожалуйста, какое значение свойства Parameterization в ваше БД?

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

Цитата:

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

Владимир Максимов,
скажите, пожалуйста, какое значение свойства Parameterization в ваше БД?

Simple

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

[Wamr]

Владимир, а я и не предлагал играться хинтами. Поведение ваших запросов нехарактерно - я пытаюсь понять в чем причина.

Я подозреваю, что при исполнении запроса с Exist у вас не происходит перестроение плана (компиляция запроса), а берется закешированный вариант, который был построен для других параметров, например, в другой компании.
Но все это возможно, только если запрос был параметризован (используется процедура sp_cursorprepare ), либо используется внутренняя параметризация сервера (параметр Parameterization БД).

[vanokh]

Цитата:

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

Я подозреваю, что при исполнении запроса с Exist у вас не происходит перестроение плана (компиляция запроса), а берется закешированный вариант...

Для того, чтобы проверить закешированный вариант или нет, можно добавить OPTION(RECOMPILE) - план каждый раз будет перестраиваться. Я для всех запросов проверил - планы не отличаются.

Parametrization установлен в Simple.

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

Почему же. Очень даже характерно. Ведь vanokh удалось повторить описанное поведение.

Просто очевидно, что для подобного поведения требуются некоторые, не очень распространенные сценарии. В частности, отстутсвие статистики подобных запросов. Сильное расхождение в количестве записей используемых таблиц (на порядки). Это то, что бросается в глаза. Возможно, есть еще что-то...

У нас ведь, транспортные накладные раньше не использовали и начали использовать только недавно. Вот и нет еще достаточной статистики. Вот и мало записей транспортных накладных по сравнению с заказами. Думаю, с течением времени, запрос по EXISTS с транспортными накладными изменит свой план выполнения и станет работать быстрее. Вот тогда его можно будет переписать на Exists.