Проблемы с Exists Join

[vanokh]

Цитата:

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

Выполните в Managment Studio два следующих запроса. Точнее, даже выполнять не обязательно. Просто посмотрите план выполнения...
А потом ответьте, откуда в первом запросе этого плана по SalesLine взялось скалярное значение для SalesId?

Ну наверняка он сращивает вместе два условия

(B.SalesId=[COLOR=blue]right[/COLOR](space(20)+[COLOR=red]'827137'[/COLOR],20)) AND (B.SalesId=A.SALESID)

и выводит по логике, что A.SALESID = Скаляр

Проверил у себя.
Для обоих запросов выполняется Clustered Index Seek, в первом - сначала по SalesLine, потом по SalesTable и Join; во втором наоборот. Если добавить OPTION (FORCE ORDER), то планы запросов станут практически идентичными - как по использованию таблиц, так и по времени выполнения.



С курсорами планы такие же, но с одним существенным отличием - поверх добавляется вставка в Tempdb, которая занимает столько же времени, сколько cам запрос, в результате время выполнения увеличивается чуть больше чем в два (!) раза. Хотя общее время выполнения все равно осталось 0,02 с

OPTION (FORCE ORDER) для курсоров не сработал



Поскольку WMSBILLOFLADINGORDER в нашей базе пустая, то провел эксперимент для связки SalesTable (около 100 тыс в одной компании) и VendTable (3500 записей). Можете привести свои планы по запросу с WMSBILLOFLADINGORDER для сравнения?

Первый запрос -

SELECT A.CUSTACCOUNT,A.INVOICEACCOUNT,A.SALESID,A.RECID 
    FROM SALESTABLE A WHERE ((A.DATAAREAID='dvc') AND (A.SALESTYPE=3)) 
    AND EXISTS (SELECT 'x' FROM VENDTABLE B 
            WHERE ((B.DATAAREAID='com') AND ((B.ACCOUNTNUM='СПЦ') 
            AND (B.ACCOUNTNUM = A.CONSIGNORACCOUNT_RU))))

SELECT A.CUSTACCOUNT,A.INVOICEACCOUNT,A.SALESID,A.RECID 
FROM SALESTABLE A, VENDTABLE B
WHERE ((A.DATAAREAID='dvc') AND (A.SALESTYPE=3)) 
     AND ((B.DATAAREAID='com') AND ((B.ACCOUNTNUM='СПЦ') 
    AND (B.ACCOUNTNUM = A.CONSIGNORACCOUNT_RU)))

План запроса:

Estimated Subtree Cost: 19 и 16 соответственно

Он же + FORCE ORDER:

Estimated Subtree Cost: оба 19

Теперь с курсорами:

Результаты одинаковы, что без. что с FORCE ORDER: 22,6 и 18,4

Выводы:

1. для простых запросов SQL строит планы хорошо и вмешательство FORCE ORDER только ухудшает дело
2. в курсорах нельзя поменять порядок FORCE ORDER (у меня во всяком случае неполучилось, может кто из грамотных спецов по SQL подскажет почему?)
3. в курсорах запрос ко внутренней таблице стал выполняться дольше (0% - 19%, хотя данные вроде те же самые) - порядок поменять нельзя см п.2. видимо дело в логике работы Left Semi Join
4. В курсорах добавляется вставка во временную таблицу, что тоже дает небольшое замедление (FETCH возвращает одну строку)