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

[mazzy]

Цитата:

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

- запрос состоит из inner join-ов, т.о. отсутствие записи в любой таблице ведет к пустому запросу

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

Цитата:

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

2) отсутствие хинтов,на мой взгляд, требует не менее пристального внимания DBA

Но при правильной настройке статистики сервер сам сможет имзенить план.
В отличие от явно заданных хинтов.
При явно заданных хинтах сервер будет использовать даже неоптимальный явно заданный план.
См. типичный пример http://axapta.mazzy.ru/lib/querytuning/

Цитата:

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

4) буду знать, даже визуально приятнее читать условия к конкретному join (в общем то следовал схеме запроса DIS слоя)

Это не "визуально приятнее".
Это особенность Аксапты. В dis-слое писали неоптимально.
Об этом писал Еременко, по-моему, в своем блоге (торможу и не могу сейчас найти)

Цитата:

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

это я и пытался довести в сообщении о счетчике сиквела 'page lookups/sec', а вот таблица из запроса никуда не исчезнет (с чего бы ей исчезать из inner join-ов)

Оптимизатор, блн.
Еще как может исчезнуть. Аксапта может разбить один запрос на несколько вложенных если в середине используется временная таблица или нет полей для выборки.

Например,
select table1 where ...
join table2 where ...
join table3 where ...

ЕСЛИ table2
1. привязана к незакупленному лицензионному ключу
2. или выключенному конфигурационному
3. или является временной
ТО на sql пойдет не один запрос, а несколько вложенных.

В некоторых сервис-паках подобные "оптимизации" выполнялись и для таблиц, для которых не выбирается ни одно поле.

То, что у вас таблица осталась в запросе еще ни о чем не говорит
Чтобы таблица гарантировано попала в SQL запрос, запрос по ней должен содержать хотя бы одно хранимое на SQL поле.
Поэтому tableId использовать опасно. TableId - не хранимое поле.

Цитата:

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

может быть - сиквел подобную подстановку сам делает.

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

[glibs]

Цитата:

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

...
Аксапта может разбить один запрос на несколько вложенных если в середине используется временная таблица или нет полей для выборки.

Например,
select table1 where ...
join table2 where ...
join table3 where ...

ЕСЛИ table2
...
2. или выключенному конфигурационному
...
ТО на sql пойдет не один запрос, а несколько вложенных.
...

Чего-то я себе это немного по-другому представлял. Можешь пояснить?

Вот джоб написал.

static void glibs()
{
InventTable inventTable;
PlInventTransExternal plInventTransExternal;
InventDim inventDim;
;

select inventTable
join plInventTransExternal
where inventTable.ItemId == plInventTransExternal.ItemId
join inventDim
where inventDim.inventDimId == plInventTransExternal.InventDimId;

}

Польша у меня отключена. Получаю (4.0):

Error Message (02:31:32) Cannot select a record in Items (InventTable).
Temporary tables must be the inner tables when joined to permanent tables.
Info Message (02:31:32) (C)\Jobs\glibs - line 8

Если польскую таблицу поставить первой, то отработает без ошибки. Только ничего не вернет. Я б тоже так поступил. Между таблицами отсутствует связь в таком случае. По-моему, логично.

Цитата:

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

...
Чтобы таблица гарантировано попала в SQL запрос, запрос по ней должен содержать хотя бы одно хранимое на SQL поле.
...

А наличие чего-то в where разве этого не гарантирует?

А если в твоем примере
table1 — это CustInvoiceJour
table2 — это CustInvoiceTrans
table3 — это InventDim
и нам нужно CustInvoiceJour.OrderAccount и InventDim.InventLocationId, то какой запрос пойдет на сервер в таком случае?

Ну, если вот так вот написать
static void glibs()
{
CustInvoiceJour custInvoiceJour;
CustInvoiceTrans custInvoiceTrans;
InventDim inventDim;
;

while select OrderAccount from custInvoiceJour
join TableId from custInvoiceTrans
where custInvoiceTrans.SalesId == custInvoiceJour.SalesId &&
custInvoiceTrans.InvoiceId == custInvoiceJour.InvoiceId &&
custInvoiceTrans.InvoiceDate == custInvoiceJour.InvoiceDate &&
custInvoiceTrans.numberSequenceGroup == custInvoiceJour.numberSequenceGroup
join InventLocationId from inventDim
where inventDim.inventDimId == custInvoiceTrans.InventDimId
{
info (strfmt("%1 -- %2", custInvoiceJour.OrderAccount, inventDim.InventLocationId));
}

}

Цитата:

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

...
Поэтому tableId использовать опасно. TableId - не хранимое поле.
...

Если по таблице необходимо наложить условие в where, то почему бы и нет?

Я поддерживаю участника Vadik в этом вопросе.

SHiSHok, как говорил... все тот же Vadik, когда я начинал учиться писать запросы в Аксапте, "* from" можно не писать.

[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 схожу.

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