вот к примеру - из BSIS+BSAS тянем записи бух.документов, там есть такое поле ZUONR, значения которое содержат какбы 2 куска - состыкованные поля KUKEY+ESNUM таблицы присвоений FEBCL (конечная цель - вытянуть из второй номер платежки, под которую был оформлен этот бух.документ).

Не нравится производительность выборки из БД ... Дело в том, что реально 90% документов, которые отбираются из BSIS, не являются платежечными (т.е. заведомо не имеют соответствия в FEBCL).

Пробовал делать так:
*1 проход, предварительно выделяем док-ты, где возможны
*платежки
select BELNR ZUONR from BSIS into itab1
where ZUONR оканчивается на 'RUB' (признак, что в бух док-те есть платежка)

*2 проход, более детальный отбор, по док-там 1 прохода
select ... from BSIS into itab2
for all entries in itab1
where
BELNR = itab1-BELNR
плюс доп-условия на основе select-options

*3 проход, выделение KUKEY ESNUM, поиск
*соответствия в FEBCL
loop at itab2
kukey1 = itab2-ZUONR(8)
esnum1 =itab2-ZUONR+9(5)
select single SELVON from FEBCL
where KUKEY=kukey1 and ESNUM=esnum1
if sy-subrc=0
* № платежки найден, чтото делаем
endif.
endloop

Вроде-бы по идее, первый проход должен отсечь нужные 10-15%
документов, вторая выборка тогда должна выполняться существенно
быстрее (чем если-бы был один select from BSIS), т.к. набор BELNR
относительно невелик. Третий select single вообще идет только по ключевым полям

Но почему-то не наблюдается увеличения производительности

Можно-ли както еще ускорить "увязку" двух плоских таблиц, если 1 поле одной нужно поделить на 2 куска, и связать из с 2 полями другой таблицы?

А на таблицы BSIS+BSAS есть индексы?

Если искать по zuonr по критерию '%RUB', то никакие индексы тут не помогут.
Если речь идет о таблицах bsis и bsas, то тут для поиска платежек, скорее, надо ориентироваться на номер счета. Для платежек это, наверное, будет 51*. БЕ тоже надо конкретизировать. Тогда хотя бы БД будет вести поиск по первичному ключу, что на порядок быстрее.
Еще можно ориентироваться на вид документа - поле blart, ну, может, еще на какие-то поля - поспрашивай настройщиков FI. Но здесь понадобится вторичный индекс. И не надо никаких хитрых алгоритмов.

да - поиск по ZUONR идет по like '__________RUB' ... т.е 8+5 цифр плюс RUB в конце ... А почему индекс тут не поможет? И можно-ли создавать доп.индекс по части символов поля (13-15я позиции) ?

1. Поскольку в условии для zuonr символы в левой части поля строго не заданы, то вторичный индекс БД использоваться не будет. Если бы было наоборот - то это пожалуйста. Те индексы, о которых ты пишешь, создать невозможно.
2. Мой совет: не парься с полем zuonr. Найди другие признаки для платежки.
3. Можно еще запланировать периодически повторяемое фоновое задание и создать собственную таблицу, в которую будут записываться номера нужных документов. Тогда не нужно разгребать все документы, а только те, которые не успели обработаться заданием. Но это не самое лучшее решение по многим причинам. См п. 2.

Не знаю у кого как а у меня на 153000 записей работает легко:

SELECT-OPTIONS: ZUONR FOR BSIS-ZUONR.

ZUONR-SIGN = 'I'.
ZUONR-OPTION = 'CP'.
ZUONR-LOW = '++++++++RUB'.
ZUONR-HIGH = ''.
APPEND ZUONR.

SELECT * FROM BSIS WHERE ZUONR IN ZUONR.

Есссесно есть индекс на BSIS-ZUONR.

Дорогуша, запустите st05 и посмотрите используется ли ваш вторичный индекс при таком селекте... Так... Ради интереса...