Проблемы с Exists Join

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

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

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)