Текущее время: Чт, сен 20 2018, 21:59

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


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


ВНИМАНИЕ!

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



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

Зарегистрирован:
Вт, сен 21 2004, 18: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, 19:34 
Младший специалист
Младший специалист

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


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

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


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

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


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

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


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

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


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

Сейчас этот форум просматривают: Google [Bot]


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

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