Здравствуйте
возникла проблема решить которую я не представляю каким образом, поэтому вынужден обратиться к форумчанам:

во внутреннюю таблицу выбраны данные из довольно таки объемной MKPF, требуется получить к каждой такой записи - поле счета, т. е. поле HKONT таблицы BSEG.
При такой задаче никак не миновать промежуточной выборки из таблицы BKPF, о размерах которой присутствующим известно. Чтобы хоть как-то оптимизировать выбор из этой таблицы (BKPF) я уже измысливал и вначале выбрать из нее заведомо больший диапазон записей, но увы, значения поля AWKEY таблицы BKPF, представляющие собой конкатенацию значений ключевых полей MBLNR + MJAHR из таблицы MKPF, оказалось никак не упорядочено, поэтому эта затея провалилась. Если же решать проблему в лоб, то выборка из таблицы BKPF продолжается неприлично долго (я при этом использовал конструкцию в SELECT'е FOR ALL ENTRIES - по нашим замерам, это абсолютно эквивалентно по скорости выполнения SELECT SINGLE ). В общем, тоже никого выигрыша.
Мало того, таблица BSEG, ради доступа к данным которой все и затевалось, не желает ни с какой другой join'ится из-за своей кластерной природы.

Вопрос: каким то образом можно решить эту задачу, минимизировав
время выборки. Я уже склоняюсь к тому, что такое вообще вряд ли возможно.

Присмотрись к таблице ACCTIT,
ее могут архивировать могут нет как у вас обстоят дела я не знаю.

Если объёмы данных большие, а сервер дохлый, то никакая оптимизация, конечно, не спасёт. Думаю, что здесь либо надо ограничивать объем данных условиями выборки, либо запускать в фоне задачу, выбирающую большой объём, анализирующую его и сохраняющую результат куда-то ещё, например, в кластерную таблицу.

Зачем BSEG джойнить, для этого пойдёт BSIS BSAS.

Что то я не понял, что где не упорядочено? Кто мешает создать индекс по полю AWKEY? Да, собственно, он обычно там уже есть. У нас, например, он под номером 4 и называется "Индекс по типу и ключу приложения".

Я имел ввиду, что значение поля MBLNR не является упорядоченным, что не позволяет просто втянуть во внутреннюю таблицу кусок таблицы БД указав его границы в запросе и спокойно с ним работать...а жаль.
Индекс у нас тоже такой есть...
вот только как показали эксперименты, запрос с SELECT SINGLE позволяет пользоваться конструкцией WHERE AWKEY LIKE..., в противоположность FOR ALL ENTRIES,
где запрещено использование LIKE.
Забавно, вопреки каноническим руководствам разработчика, предложение с LIKE отрабатывает быстрее, нежели с обычным оператором сравнения...причина видимо в том, что, в таком случае, сравниваются напрямую строки и не происходит никаких дополнительных попыток преобразований.
Что касается производительности сервера, думаю что один из немногих САМЫХ производительных, какие только есть в природе.

За идеи различные большое спасибо.

Индекс в запросах используется, только если сравнение EQ.
Если NE, и тем более LIKE, индексы не применимы, насколько я понимаю.

Поэтому очень желательно писать WHERE AWKEY = 'xxxxx'.

а посмотреть план запроса слабо?
что касается like, то он работает по seek по индексу в том случае, если начало значения - НЕ переменная часть
что-то вроде
WHERE AWKEY LIKE '44600%'
т.ч. ничего удивительного нет

что касается FOR ALL ENTRIES, помнится есть нота 77013
посмотрите, какое значение у вас имеет в rsdb/prefer_union_all