Добрый день.
Допустим, есть loop at itab where ...
Как понять, использовал loop сортированный ключ таблицы itab для ускорения доступа или нет?

Если таблица удовлетворяет требованиям и where использует все ключевые поля то 100%

А так сравнительным тестом на объеме

Там довольно сложное условие. Сначала идут поля ключа, потом всякие хитрые условия.
Сравнительный тест делать последнее дело, я надеялся, что это где-то в отладчике или SAT можно посмотреть.

По-моему LOOP AT всегда использует первичный ключ: сапгуй любит выдавать предупреждения, что используется первичный ключ, хотя (почти) все поля непервичного ключа обеспечены.
Возможно, сап не может определить, какой будет быстрее и поэтому оставляет первичный, требуя явного указания ключа.
Возможно, зависит от версии.

Нашел в help такой вариант: объявить ключ как вторичный и явно требовать его использования в loop


Тогда там где система не может использовать ключ, будет ошибка на этапе компиляции

Все верно, если таблица объявлена только как type table of, то loop будет по всем записям проверять условия.
Если объявить с вторичным ключом (сортед) и использовать using key цикл будет только по записям соответствующим ключу (поиск записи аналогичен binary search при read table).

Но этот способ иногда работает дольше (особенно если много insert/append), чем отсортировать таблицу и запускать loop с индекса