оптимизируем запросы.

[SHiSHok]

Цитата:

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

Ну и что?
Если таблица markupTrans содержит значительно больше записей, чем таблица FatureTrans, то почему надо начинать именно с MarkupTrans?

потому что в описанной ситуации из FaсtureTrans_RU выберется множество записей с заданными FACTURELINETYPE и MODULE (минимум 1) и по КАЖДОЙ из них будет сделан lookup из MARKUPTRANS по полю MARKUPREFRECID. Только в этом случае у нас будет не менее одного обращения к большой MARKUPTRANS , а в случае с ведущей таблицей MARKUPTRANS - гарантировано 1 index seek. Я так думаю
Единственное когда план плох - это когда в FaсtureTrans_RU по условию (FACTURELINETYPE, MODULE) вообще нет записей и таблица намного меньше MARKUPTRANS. Но надо посмотреть код - может при таких условиях код не будет исполнятся и вовсе.

Цитата:

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

Оптимизатор, блн.

да уж приходится. на базе под 100Gb мнооого чего вылезает...

Цитата:

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

Нет, не делает.

поправочка: в сиквел передается условие as is (C.MODULE=B.MODULE), а в плане исполнения уже все подставляется как надо (C.MODULE=0).

Немного в продолжение:
На сиквеле у меня все как надо: дефрагментаниция нужных таблиц в нужное время , обновление статистики, и т.д.
Вспомнив обсуждение одного запроса с Киселевым, сделал следующее:

update statistics factureJour_RU with fullscan
update statistics factureTrans_RU with fullscan
update statistics markupTrans with fullscan
update statistics custInvoiceTrans with fullscan
dbcc freeproccache

план не изменился - сиквел идет в первую очередь по FACTURETRANS_RU (11млн. записей),а не по MARKUPTRANS (2млн. записей). Но это уже по свободе на sql.ru схожу.

ЗЫ: Я не навязываю своего решения никому!