У тебя похоже дело не в full scan, а в том, что создается временная таблица для сортировки.

CLIENT SPECIFIED пробовал ставить?

UPD: Видишь, по другому индексу пошел
INDEX RANGE SCAN S987~VAB
Что за индекс?

MANDT
MATNR

Задействует, видимо как раз из-за разрыва ключа (выпадает VBELN).

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

В данном эхплайн плане видно, что подцепился не тот индекс. То есть база, использую неверный индекс не имеет информации о сортировке, чтобы выполнить твой group by и поэтому вынуждена сначала создать промежуточную таблицу, отсортировать ее , а потом только по ней обработать запрос.

Короче, если CLIENT SPECIFIED не поможет, используй %_HINTS c явным указанием индекса.

Млин. Стремно мне переставлять ключевые поля местами в такой громадной таблице (VBELN задвинуть подальше).

Попробую составить вторичный индекс, который будет повторять ключ, но без VBELN (хотя, млин, тоже затратно получается). И укажу хинтом.

так может просто хинтом индекс скормить первый - да посмотреть скорость

Только-только индекс сактивировался (все ж 60 лимонов записей), поэтому только сейчас отвечаю.
Теперь выполняется как надо.

На самом деле, мне в принципе было интересны причины такого странного поведения.

Попробуйте если не трудно указать хинтом на первый индекс - очень интересно что из этого получится.
А по поводу причин - боюсь наговорить глупостей, но это срывает крышу оптимизатору запросов. Как одна из возможных причин такого крышесрыва - давно не обновляемая статистика по индексам

Витя, лучший способ угробить систему, это создать с пяток таких индексов на частообновляемую таблицу на 60 млн. записей.

Отчет может раз в год будет нужен, а база будет тормозить постоянно.

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

ЫХ, да знаю я, Валер, но нет уже сейчас времени на эксперименты .
А убивать сейчас этот индекс и потом заново создавать тем более нет времени.
Тем более, что перенос каждого ТрЗ в продуктив - определенный гемор (с точки зрения согласования и времени исполнения).

Хотя... может, завтра останется время свободное, тада попробую хинт другой указать.

Еще хочу сказать - не было у этой таблицы ни одного индекса, кроме этого S987~VAB .
S987~0 - системный индекс. Я так думаю, индекс по ROWID, когда не используется вторичные индексы и поиск идет только по первичному ключу.

Ничего странного, всё очевидно. Четко оптимизируюется только условия "=" объединенные "AND". Соответственно, исходя из этого, нужно строить индексы, помещая поля, выбираемые по "=", вверх ключа.

У меня есть одна любопытная мысля. Что, если создать таблицу дат, накладывать условие интервала на нее, а уже с ней по "=" джойнить нужную таблицу?!

Ну я, честно сказать, за 7 лет работы столкнулся с такими чудесами впервые.



Наверняка есть такая, сейчас память изменяет .
Обычно выборки идут за месяц.

Чудеса продолжаются.
Программа заполнения инфосистемы.
Крутится, но нифига не обновляет. Изначально, программа обновления была с ошибкой, не заполнялось два поля.
Затем была разработана программа для обновления только этих 2-х полей (по уже имеющимся записям).

Код:


Так вот, селектом выбираются... несуществующие записи.
Т.е. ставим точку прерывания сразу за SELECT... , ищем запись с таким ключом в SE16 и... не находим .

Внутри конструкции SELECT... ENDSELECT стоял оператор


Он отрабатывал с SY-SUBRC=0, НО ЗАПИСЬ В ТАБЛИЦЕ НЕ ПОЯВЛЯЛАСЬ!!!
Затем был заменен на


Понятно, что стало SY-SUBRC=4 .

НЕ ПОНИМАЮ!

я стесняюсь уже навязываться, но пусть базис попробует пересобрать статистику по этой таблице

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

Select и SE16 - далеко не одно и то же. Ключи, введенные на экране SE16 сначала преобразуются. Могут быть удалены лидирующие нули, или наоборот, добавлены. Или из внешнего представления переведены во внутренее.


Modify отличается от Update тем, что Modify добавит запись, если она не существует, а Update может модифицировать только существующие.