Это не совсем правильно. Если такой индекс вам все таки нужен - то лучше будет его сделать например таким: 'MANDT BUKRS STBLG STJAH'.
Но без необходимости индексы не лучше создавать - бесполезная трата ресурсов БД

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

Спасибо, буду иметь ввиду

Не обязательно, но там есть нюансы
Развернуто о этих нюансах можно почитать в книге 'ABAP Perfomance Tuning', Hermann Gahm
ИМХО в общем случае лучше все таки включать поле MANDT в индекс

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

увы
Сам взял бумажную почитать у коллеги

Руководствуясь здравым смыслом и революционным чутьем всегда ставлю MANDT в индексы, т.к.:
1. SAP в любой SELECT невозбранно вставляет условие выбора по манданту.
2. Я предпочитаю INDEX SCAN без SKIPа.
3. Доп. нагрузка на СУБД при вставке записей меняется в микромасштабах в случае включения/исключения манданта.

Про мандант в начале индекса - есть небольшое противоречие которое меня всегда смущало:
По теории в начале индекса надо размещать поля с наибольшей селективностью, а у поля мандант как правило селективность низкая (можно сказать в обще никакая)
С другой стороны мандант присутствует во всех запросах к таблице (специфические случаи в расчёт не берём)

Вот и думай как тут правильно делать.

Я обычно всё же ставлю мандант в начало индекса

А зачем тогда при выборке вообще использовать BUKRS?
Ключевыми полями для MSEG являются MBLNR MJAHR и ZEILE.
Кроме этого перед SELECT нужно проверить SMBLN на непустое значение и только тогда делать SELECT.

это я лишку хватил
Просто обычно задача по удалению сторно ставится от обратного - берутся все записи за период, затем ищутся документы сторно (SMBLN is not initial) и по ним убираются сторнированные документы

САПовцы сами по-разному делают...если примеров с мандантом в начале индекса достаточно много, то в табличке GLREFO есть пример обратного подхода.

Воистину, "думай как тут правильно делать"! Ибо теория про наибольшую селективность для тех, кто совсем не хочет думать. Сам термин "селективность" неотъемлем от "Select", т.е необходимо рассматривать конкретные запросы, их условия, частоту их использования. С этой точки зрения, например, поле "MANDT" стоит абсолютно правильно в начале всех индексов.

p.s.
В своё время я даже с одним базисником поспорил об оптимальности построения индекса, решили протестить. Он построил один индекс исходя из селективности, другой исходя из моих рекомендаций. Выборка по моему индексу с небольшим отрывом победила.

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

Это в случае, если большинство запросов к таблице идет по одним и тем же полям.
Если индекс планируется использовать в разных запросах, то расположение полей в нем нужно строить исходя из условий всех этих запросов.

Если я правильно понимаю, для тех документов, для которых нет документов сторно, это поле "пусто" (initial).
То есть например 10-20% записей имеют непустые эти поля (в лучшем случае), а остальные "пустые".

В этом случае это "плохой" индекс. У него большая селективность, но значения = initial занимают большую часть записей. Поэтому любое условие stblg = ' ' (типа нет документов сторно) может приводить к "подвисанию" селекта. Это связано с тем, что оптимизатор видя хорошую селективность выбирает этот индекс, но выборка по пустому значению по сути равняется full scan-у.

Если не вам, то вашим коллегам или даже стандарту индекс может очень навредить. Лучше таких индексов избегать. Но если такой индекс все-таки пришлось создать, желательно избегать условий вроде stblg = ' ' (ну и stjah, bukrs тоже, я просто опускаю для простоты).