Оптимизация запросов select

Ряд рекомендаций:
1. Отказаться от into corresponding fields of table в пользу into table. Причём выводить только нужные поля.
Очень хорошо помогает.
Однако для этого надо обеспечить, что порядок и тип полей в таблице-получателе совадал с порядком полей запроса.

2. Не смешивать в запросе буферизованные таблицы и не буферизованные: буферизация работать не будет. Лучше вынести получение в отдельные подзапросы - можно даже в цикле, работает быстро.
На примере заполнения имён заводов и складов:
select [...] from [...] into table RES_TB where [...].
FIELD-SYMBOLS <res_fs> TYPE res_tp.
LOOP AT RES_TB ASSIGNING <res_fs>.
SELECT SINGLE name1 into <res_fs>-werks_t from t001w where werks = <res_fs>-werks.
SELECT SINGLE LGOBE into <res_fs>-LGORT_t from t001l where werks = <res_fs>-werks and lgort = <res_fs>-lgort.

endloop.

3. Например, в конструкции where есть ограничения "fielndname <> 'X'". А список допустимых значений этого поля небольшой и известен или может получен взят из справочника. Лучше постараться заменить на "=" в каком-либо виден (in, for all entries). либо вообще получить избыточные данные и отбросить их программным кодом (delete [...] where "fielndname = 'X'").

4. Например, результат первого запроса (tab1) используется во втором запросе (tab2), а потом эти данные собираются в общую таблицу. Примерно так:
loop at tab1 assigning <tab1_fs>.
read table tab2 into ls_tab2 with key field1 = <tab1_fs>-fielnd1 [...].
<tab1_fs>-field5 = ls_tab2-field5.
" либо цикл по второй таблице с аналогичным фильтром
endloop.
На больших объёмах такая сборка может быть очень медленной.
В таких случаях бывает полезно объявить таблицу tab2 как hash, если это возможно.

5. В фильтрах и соединениях таблиц чтобы использовался индекс надо перечислить поля, стоящие выше в индексе. Даже если там константа.
Например, в таблице A512 ключ из полей: MANDT, KAPPL, KSCHL, VKORG, BWTAR, MATNR, KFRST, DATBI. А в фильтре используется только vkorg, BWTAR, matnr, а KAPPL, KSCHL - константы. Необходимо перечислить эти два поля. MANDT - необязательно, его подставит система.

см также по FOR ALL ENTRIES

to be continue... Подробнее...

Подводные камни FOR ALL ENTRIES

1. Если результаты одного запроса используются в конструкции for all entries второго - не забываем проверять, что таблица пустая. Иначе второй запрос не посчитает это ограничением.
select [...] into table table1 from [...] where [...].
if table1 is not initial.
select [...] into table table2 from [...] for all entries table1 where [...].
endif.

2. При For all entries могут не выводиться дублирующиеся строки (как будто используется параметр distinct).
Необходимо перечислить в списке полей вывода все ключевые поля всех используемых в запрос таблиц (причём даже если значение каких-то из них фактически одинаковые).
Проблема похоже в том, что такой запрос преобразуется системой в набор запросов, объединённых через метрику UNION, а не UNION ALL.

3. Например в конструкции where запрос используется набор полей из таблицы конструкции for all entries, а значения эти неуникальные в таблице (например только номера документов, а в таблице встречаются и позиции).
Такой запрос можно ускорить:
data tab_copy like tab. " либо type с тем же типом
tab_copy = tab.
sort tab_copy by vbeln." список полей, используемых в for all entries
DELETE ADJACENT DUPLICATES FROM tab_copy COMPARING vbeln. " тот же список полей
И в запросе использовать эту таблицу.

4. Иногда полезно убрать лишние фильтр по значениям из таблицы for all entries (например, вместо vbeln+posnr[+etern] оставить только vbeln) и применить пункт 3.
Особенно когда известно, что скорее всего в таблице источнике перечислены все или многие значения исключаемых полей.
Пусть даже будет какая-то избыточность данных, но запрос отработает значительно быстрее. Подробнее...