Цитата:

В запросе соединение-то наверно внутреннее стоит, а надо внешнее левое поставить.

kms писал(а) 18. Августа 2008 :: 17:09:

kms
Спасибо за соболезнования
Да ясно же, что причина наверняка простая. Поковыряю пока сам.

Цитата:

Не подскажет ли Dmitro как тип соединения может влиять на быстродействие?
или хотя бы ссылочку где почитать можно.
Заранее огромное спасибо!

Ну вы что, господа? Первый раз замужем чтоли? Это же старая, известная фишка любых sql серверов.

Если несколько источников данных соединяются внутренним соединением (inner join), то оптимизатор запросов получает дополнительное пространство для раздумий: первичный проход можно делать по любому из источников данных, а данные из остальных источников выбираются букмарк лукапом, при этом отдается предпочтение кластерным индексам.
select
   t1.f1
   t2.f2
from t1
inner join t2 on t1.id = t2.id
where t1.d > 3 and t1.d < 23 and t2.f2 = 234

Предположим, что есть индекс по полю d, и кластерные индексы по полям id.
Такой запрос имеет два очевидных, конкурирующих плана выполнения:
1)Переход по индексу (Index seek) t1.d по условию t1.d > 3; проход по индексу до условия t1.d < 23; при проходе выполняя два перехода по кластерным: Bookmark lookup во-первых для t1 чтобы достать поле f1, во-вторых для t2 чтобы достать поле f2. Оптимизатор считает Bookmark lookup весьма тяжелой операцией.
2)пройти по кластерному индексу t2.id с условием t2.f2 = 234; и сделать для выбранных записей один переход по кластерному: Bookmark lookup в первичную таблицу t1, для получения f1 и оценки сразу всех остальных условий t1.d > 3 and t1.d < 23, а если еще в базе будет индекс по полю t2.f2, тогда вообще фиг знает какой план победит (скорее этот).

При этом оптимизатору предписано оценить эффективность различных вариантов плана выполнения по нескольким критериям (количество чтений, количество внутренне передаваемых данных, типы операций, утилизация проца и т.п., там разные коэффициенты по разным критериям). А как он (оптимизатор) это делает, если запрос еще только предстоит исполнить? Это делается на основе статистики. А статистика вещь хорошая только когда она в надлежащем состоянии. К сожалению не редки случаи когда на основе не объективной статистики (да и коэффициенты тоже людьми проставлены) и в пограничных вариантах оптимизатор выбирает не тот план выполнения. (Кстати на SQL 2005 оптимизатор в этом отношении умнее)

Вернемся к нашему примеру: если мы заранее знаем характер наших данных, то чтобы оптимизатор даже не сомневался, какую таблицу выбрать в качестве основы выборки, мы можем указать левое соединение вместо внутреннего:
select
   t1.f1
   t2.f2
from t1
left join t2 on t1.id = t2.id
where t1.d > 3 and t1.d < 23 and t2.f2 = 234

Тогда у оптимизатора не остается выбора: основной таблицей с которой он начнет проход будет t1 (точнее даже это будет таблица индекса t1.d).

DmitrO писал(а) 19. Августа 2008 :: 06:09:

Не знал. Спасибо. Пошел курить свои "трудные" запросы.

а мне то, кто-нить поможет?

Такие посты надо в FAQ 

тоесть а проще никак?