Текущее время: Пт, мар 29 2024, 15:41

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: Оцените селект
СообщениеДобавлено: Вт, сен 21 2004, 18:25 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, сен 21 2004, 17:54
Сообщения: 67
Господа опытные абаперы.
Посмотрите плиз на этот селект и скажите ваше мнение по поводу его оптимизации.
SELECT mara~mtart mseg~matnr makt~maktx mseg~lifnr
mseg~charg ekko~bedat mseg~ebeln mseg~ebelp
ekpo~menge ekpo~meins ekpo~konnr ekpo~ktmng lfa1~adrnr
INTO TABLE lt_sel_data
FROM mseg
JOIN mara ON mara~matnr = mseg~matnr
JOIN ekko ON ekko~ebeln = mseg~ebeln
JOIN ekpo ON ekpo~ebeln = mseg~ebeln AND
ekpo~ebelp = mseg~ebelp
JOIN lfa1 ON lfa1~lifnr = mseg~lifnr
JOIN makt ON makt~matnr = mseg~matnr AND
makt~spras = sy-langu
WHERE mseg~matnr IN s_matnr
AND mseg~werks IN s_werks
AND mseg~lgort IN s_lgort
AND mseg~smbln = ' '
AND mseg~lifnr IN s_lifnr
AND mseg~charg IN s_charg
AND mara~mtart IN s_mtart
AND mara~matkl IN s_matkl
AND ekko~ekorg IN s_ekorg
AND ekko~ekgrp IN s_ekgrp
AND ekko~ebeln IN s_ebeln
AND ekko~bedat IN s_bedat
AND NOT EXISTS ( SELECT * FROM *mseg
WHERE smbln = mseg~mblnr
AND sjahr = mseg~mjahr
AND smblp = mseg~zeile )
ORDER BY mara~mtart mseg~matnr mseg~lifnr mseg~charg
ekko~bedat mseg~ebeln mseg~ebelp.

Ну да, заджойнено много, но ведь по ключу - на мой взгляд, все быстрее, чем потом в цикле по внутренней таблице делать select single (или что-то еще такого плана, типа for all entries всякие).
Условия под where вроде тоже перечислены в правильном порядке.

При условии, что все указанные ограничения по перечисленным полям и таблицам должны иметь место - ваше мнение, нужно и можно ли его оптимизировать и как?
/на то, что MAKT джойнится не по LEFT JOIN - не совсем хорошо, но пусть пока, не обращайте внимания/


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: abaper
СообщениеДобавлено: Вт, сен 21 2004, 18:34 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, сен 21 2004, 17:54
Сообщения: 67
Небольшое уточнение - из MSEG вообще говоря интересует только CHARG, при условии, что lifnr ebeln ebelp не пусты. Но селект-то по-любому нужен какой-то.....


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, сен 22 2004, 10:16 
Гость
у тебя куча рангов, поэтому непонятно, какой будет план запроса. Надо получить планы запросов (st05) для наиболее часто используемых вариантов вызова запроса. Проанализировать на использование индекса.
для 46С
в exists будет использоваться индекс S
Если в условиях отбора будут материал \ завод \ склад - то будет использоваться индекс M. но это в том случае, если ранги будут относительно небольшими. Может оказаться лучше переписать на for all entries (если указано правильное значение параметра, который определяет построение запроса с for all entries)

повторяю, информации недостаточно


Принять этот ответ
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, сен 22 2004, 11:13 
Старший специалист
Старший специалист

Зарегистрирован:
Ср, авг 18 2004, 09:17
Сообщения: 477
Откуда: Москва
Пол: Мужской
abaper:
Во-первых, нужно опредлиться какие цели ты преследуешь для оптимизации запроса. Не устраивает текущее быстродействие?
Мне, например, не очень нравятся многоэтажные джойны из-за их громоздкости. Но это дело вкуса. Хороший с точки зрения быстродействия результат всегда получается после длительного тюнинга и как минимум 3х-4х вариантов извлечения данных.
Что сразу бросается в глаза - where clause. Если таблицы s_* заполняются через select-options, допускающим многократный выбор, то пользователю пара пустяков ввести такой критерий выборки, который приведет к полному перебору одной из указанных там таблиц.
Коррелированный подзапрос ничего сильно не замедлит, потому как выполнится по вторичному индексу. Ну, и сортировку результирующей выборки лучше выполнить на abap'e. Можно просто объявить lt_sel_data как sorted table.
И потом, проанализируй в среднем количество выбираемых данных, которые будут делать пользователи. Если в результате запроса, как правило, выбирается несколько десятков записей, то такой join отнюдь не оптимальный выбор.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, сен 22 2004, 13:38 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, сен 21 2004, 17:54
Сообщения: 67
ok


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB