В очередной раз столкнулся с оптимизацией запроса. Выборка из BSIS. У меня в условии поле около 7.
Некоторые из них задаются на селекционном экране. Целый час подбирал индекс, чтобы в условии написать полу в порядке следования их в индексе. При этом те поля, которые могут остаться пустыми старался не учитывать. И получилось всё-равно не очень шустро.
А теперь внимание, вопросы
1) Действительно ли необходимо поля в условии писать в порядке следования их в индексе чтобы при выборке этот индекс использовался?
2) Может существует в природе ФМ, который динамически генерирует SELECT, подбирая нужный индекс?

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

Создание индексов на 7 полей для BSIS? Админы съедят.
К тому же некоторые поля на селекционном экране и пользователь их может заполнить, а может не заполнить. Так что тут индексы не помогут.
Но в общем в данном случае это больше академический интерес. Т.е. интересует не конкретный случай, а общий. Ну раз нет, значит нет.
Придется самому писать, если что.

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

А селективность полей не пробовали посмотреть?
Глядишь, в выборке 4 поля останутся вместо 7-ми

• Возможно, часть полей получится сделать обязательным.
• Возможно, фильтр по некоторым полям не сильно повлияет на скорость выборки(про селективность вам уже говорили)
• Рассмотрите вообще какие наборы параметров наиболее часто используются.
• Возможно, для разных ситуаций придется по-разному организовать выборку

Имхо, имеет смысл заниматься оптимизацией конкретных ситуаций (наиболее популярных), а не всех возможных

По моему мнению в SAP вообще БД самые примитивные.
Вот такой код

работает раз в 5! быстрее вот такого

После таких примеров возникают мысли, что в SAP запросы вообще никак не оптимизируются при выполнении.

Запросы выполняются в БД. Каким "SAP должен оптимизировать"?
Вы, разумеется, разобрались в причинах такого поведения, прежде чем у вас сформировалось такое мнение?

В данном случае я выразился неточно. Конечно, запрос к БД должен оптимизировать не SAP, а БД. Но по моему мнению любая современная БД должна выполнять такой запрос быстро.
Объяснение такого поведение я придумал следующее:
В ключе только первые три поля. Когда выбираю по ключу, а потом удаляем ненужное, то как раз SAP быстро делает это в памяти.
БД быстро выбирает по ключу, но по доп. полям она выбирает медленно. Т.е. получается примерно следующее:
Случай 1.
Запрос в БД выбирает данные по индексу быстро. Потом в памяти обработка идет быстро, так как все данные уже в памяти.

Случай 2. Запрос в БД медленный, так как в запрос присутствуют поля, коорые не включе. Т.е. БД быстро находит кусок, который относится к индексным полям, а потом долго и нудно перебирает этот кусок данных для нахождения строк, которые удовлетворяют оставшимся двум полям, которые не в индексе.


Но это мои домыслы, не подкрепленные фактами

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