Самый эффективный способ SELECT в кластерной таблице?

Мне удалось решить проблему с производительностью, добавив в фильтр поле OBJECTCLAS в дополнение к OBJECTID. Это изменение значительно сократило время обработки.

После добавления поля OBJECTCLAS выбор выглядел так:

IF lt_chunk_cdhdr is not INITIAL.

    SELECT OBJECTID
           CHANGENR
           FNAME
           CHNGIND
           VALUE_NEW
           VALUE_OLD
      FROM CDPOS
      INTO TABLE lt_temp_cdpos
      FOR ALL ENTRIES IN lt_chunk_cdhdr
      WHERE OBJECTID = lt_chunk_cdhdr-objectid
      AND   OBJECTCLAS = lt_chunk_cdhdr-OBJECTCLAS.

    LOOP AT lt_temp_cdpos INTO ls_cdpos.
      CHECK ls_cdpos-fname = 'FRGKE' AND ls_cdpos-value_new = '2'
         OR ls_cdpos-fname = 'MWSKZ'
         OR ls_cdpos-fname = 'KEY' AND ls_cdpos-chngind = 'I'
         OR ls_cdpos-fname = 'BRTWR'
         OR ls_cdpos-fname = 'NETWR'
         OR ls_cdpos-fname = 'ZTERM'
         OR ls_cdpos-fname = 'INCO1'.

      APPEND ls_cdpos TO lt_cdpos.
    ENDLOOP.
ENDIF.

В моем первоначальном подходе я использовал только поле OBJECTID для фильтрации оператора SELECT в таблице кластера CDPOS. Однако, включив также поле OBJECTCLAS, база данных смогла оптимизировать запрос гораздо эффективнее, что привело к значительному повышению производительности.

Раньше при фильтрации 35 идентификаторов время обработки программы составляло около 1 минуты 15 секунд, но теперь с изменением время сократилось до 3 секунд.

Таким образом, мы можем заключить, что для оптимальной производительности оператора SELECT в кластерной таблице необходимо фильтровать, используя только ключевые поля в предложении WHERE, и включать как можно больше ключевых полей. Кроме того, не рекомендуется фильтровать неключевые поля в инструкции SELECT; вместо этого используйте команду ПРОВЕРИТЬ, чтобы впоследствии отфильтровать эти поля.

В системе ABAP до версии ABAP 7.53 (*) «таблица кластера» — это «вещь» ABAP, которая не известна системе базы данных как таблица: данные таблицы кластера сжимаются ядром ABAP и сохраняются внутри его. «кластер таблиц», который представляет собой таблицу в базе данных (**).

Например, CDPOS — это таблица кластера, а CDCLS — ее кластер таблицы (см. скриншоты ниже). CDCLS также содержит таблицу кластеров PCDPOS (все ее таблицы кластеров можно увидеть через «список использования» кода транзакции SE11).

Базе данных известны только столбцы первичного ключа кластера таблиц. Остальные столбцы таблицы кластера сжаты в один большой столбец таблицы кластера, они не могут быть запрошены напрямую из базы данных, они известны только ядру ABAP.

Ваш ABAP-запрос к таблице кластера будет преобразован в запрос к кластеру таблиц и отправлен в базу данных (***), поэтому при кодировании запроса вы должны применить к кластеру таблиц те же советы по повышению производительности, что и для других классических запросов. таблицы («Прозрачные таблицы» в SE11), т. е. вы должны фильтровать данные по ключевым столбцам кластера таблиц, в конечном итоге вы можете опустить любой из последних ключевых столбцов, но не первые, иначе это может быть довольно медленно. Остальные столбцы не важны для повышения производительности, поскольку они неизвестны базе данных.

CDCLS имеет этот первичный ключ:

• MANDT (не требуется, поскольку неявно добавляется ядром ABAP)
• OBJECTCLAS
• OBJECTID
• CHANGENR

Вот скриншоты кода транзакции SE11, которые показывают, является ли таблица кластерной (CDPOS), и информацию о ее кластере таблиц (CDCLS):

(*) Кластер таблиц - Глоссарий ABAP:

«До версии 7.53 таблица базы данных содержала данные нескольких кластерных таблиц. Таблицы кластеров больше не поддерживаются с версии 7.53, и все кластеры таблиц были удалены».

(**) Вот как данные хранятся в кластере таблиц, авторские права help.sap.com, извлечено 5 июля 2024 г.:

(***) Вы можете использовать код транзакции ST05, чтобы запустить трассировку SQL и посмотреть, как ваш SQL-запрос ABAP преобразуется в запрос к кластеру таблицы базы данных.

Извините, я пока не могу использовать комментарии. Однако это 2 цента для @Lucas Ag. Конечно, это зависит от базы данных, но обычное практическое правило для хорошей производительности SQL-запроса заключается в предоставлении полей, подкрепленных индексом, начиная с первого поля (наиболее общего) и затем до последнего (наиболее общего). подробно). То есть дело не в том, чтобы просто предоставить как можно больше ключевых полей, а в правильном порядке. То есть в случае кластерных таблиц единственным имеющимся индексом является первичный ключ. Допустим, lt_chunk_cdhdr содержит все документы изменений для данного идентификатора класса/объекта. Рассмотрим приведенные ниже два запроса, оба из которых относятся к двум ключевым полям в предложении where:

    SELECT OBJECTID
       CHANGENR
       FNAME
       CHNGIND
       VALUE_NEW
       VALUE_OLD
    FROM CDPOS
    INTO TABLE lt_temp_cdpos
    FOR ALL ENTRIES IN lt_chunk_cdhdr
    WHERE OBJECTID = lt_chunk_cdhdr-objectid
    AND   OBJECTCLAS = lt_chunk_cdhdr-OBJECTCLAS.

    SELECT OBJECTID
       CHANGENR
       FNAME
       CHNGIND
       VALUE_NEW
       VALUE_OLD
    FROM CDPOS
    INTO TABLE lt_temp_cdpos
    FOR ALL ENTRIES IN lt_chunk_cdhdr
    WHERE OBJECTID = lt_chunk_cdhdr-objectid
    AND   CHANGENR = lt_chunk_cdhdr-CHANGENR.

Оба запроса имеют только два ключевых поля в предложении where, но запрос №2 будет (намного) медленнее. Однако для достижения максимальной производительности я бы рекомендовал заполнить все 3 ключевых поля — в любом случае они у вас уже есть в таблице lt_chunk_cdhdr. Причина: внутренний перевод for all entries в собственный запрос к БД и последствия этого. Например, если ваш объект относится к классу KRED (поставщик) с идентификатором «1234567890» и имеет 50 документов изменений (то есть 50 записей в CDHDR), ядро ​​ABAP может преобразовать его во что-то вроде:

    select <list of fields> from cdpos
    where mandtant = <your current system client>
    and objectclas = 'KRED' and objectid = '1234567890'  --record #1
    union all
    select <list of fields> from cdpos
    where mandtant = <your current system client>
    and objectclas = 'KRED' and objectid = '1234567890'  --record #2
    union all
    ...
    union all
    select <list of fields> from cdpos
    where mandtant = <your current system client>
    and objectclas = 'KRED' and objectid = '1234567890'  --record #50

Такое поведение наблюдалось в MS SQL. В Oracle же вместо OR стоит UNION ALL. Вышеупомянутое показывает следующее:

• данные выбираются гораздо меньшими порциями, чем во внутренней таблице, что зависит от максимального размера оператора SQL и аналогичных ограничений БД;
• если в запросе указаны только общие поля, БД придется вернуть один и тот же набор из 50 записей для каждого частичного ПК (ну, это наш пример с 50 документами изменений для данного объекта; конечно, оптимизатор БД довольно умен и выиграл так не делаю, но это лишняя нагрузка на БД).

Итог: самый эффективный способ select ... for all entries — указать в запросе полный ПК:

    SELECT ...
    FROM CDPOS
    INTO TABLE lt_temp_cdpos
    FOR ALL ENTRIES IN lt_chunk_cdhdr
    WHERE OBJECTCLAS = lt_chunk_cdhdr-CHANGENR
    AND   OBJECTID = lt_chunk_cdhdr-objectid
    AND   CHANGENR = lt_chunk_cdhdr-CHANGENR.

Надеюсь, это кому-то поможет.