Цитата:
Сообщение от
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
может быть - сиквел подобную подстановку сам делает.
Нет, не делает.