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

[SHiSHok]

Цитата:

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

Во-первых, с чего вы взяли, что так будет всегда и у всех.
Во-вторых, явные хинты требуют постоянного административного внимания.
В-третьих, с какой стати у вас сиквел сам этого не понимает? Разберитесь именно с этим.
В-четвертых, где-то в блогах, по-моему, Еременко писал, что условия после всех join'ов в Аксапте работает медленнее, чем условия внутри.

1) думаю будет:
- запрос состоит из inner join-ов, т.о. отсутствие записи в любой таблице ведет к пустому запросу
- множество записей в markupTrans обозначено явно (TransTableId + TransRecId)
- каждая запись в множестве markupTrans ссылается на 1 (и более) записей в FACTURETRANS_RU - FACTURETRANS_RU.MARKUPREFRECID=MARKUPTRANS.RECID (есть индекс по этому полю)
- каждая запись из множества FACTURETRANS_RU ссылается на 1 запись в FACTUREJOUR_RU - это может быть одна и та же запись(FACTUREJOUR_RU.FACTUREID=FACTURETRANS_RU.FACTUREID, MODULE фиксирован - есть уникальный индекс)

= Таком образом выбираются только необходимые данные от меньшего к большему (нет ибыточной выборки) - Не вижу более оптимального плана для данного запроса.
2) отсутствие хинтов,на мой взгляд, требует не менее пристального внимания DBA
3) поработаю над сиквелом.
4) буду знать, даже визуально приятнее читать условия к конкретному join (в общем то следовал схеме запроса DIS слоя)

Цитата:

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

Про recId и TableId тоже писали. Суть в том, что TableId - аксаптовское поле, не хранимое в базе СКЛе. Это значит, что использование TableId может привести к тому, что таблица исчезнет из SQL-запроса.

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

Цитата:

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

Обратите внимание на порядок полей в условиях.
1. Порядок полей должен по возможности совпадать с порядком полей в индексе (в противном случае SQL должен выполнить доп-работу)

учту.

Цитата:

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

2. Если у вас задействуется несколько индексов, то сначала укажите самый селективный (см. factureTrans)

не совсем понял.

Цитата:

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

3. Обратите внимание на проверку на модуль. Лучше сравните с константой, нежели поля таблиц

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

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

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

[Vadik]

Цитата:

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

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

Оформление данного запроса - не тот стиль, которого стоит придерживаться. Он трудно читается, в нем трудно искать ошибки при отладке
SQL Style - FROM x,y,z or INNER JOIN; We are all Cowboy Coders

На производительности запроса с использованием только INNER JOIN и AND-условий такое оформление не сказывается никак (оптимизатор это щелкает как орехи), скорее неряшливость в оформлении кода. "Выстрелить" это может при использовании EXIST и NOTEXIST JOIN

Цитата:

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

Это особенность Аксапты. В dis-слое писали неоптимально.
Об этом писал Еременко, по-моему, в своем блоге

действительно, куда же еще это писать, если не в блог

Цитата:

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

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

по-моему, ты что-то с чем-то путаешь.. в любом случае, при отключенной table2 что один запрос, что несколько - приводят к пустой выборке