Судя по всему ваш индекс недостаточно селективен с точки зрения Оракла (большое число уникальных значений) и тот считает более предпочтительным использовать фуллскан всей таблицы.
Если действительно видите потерю производительности и готовы спорить с Ораклом есть решение у базиса - взять статистику в разработке(где индекс цепляется) выгрузить ее, загрузить в продуктив и залочить(запретить обновление).
Сами сталкивались с ситуацией, где саппорт развел руки и предложил такое решение, так что вполне работоспособно. Единственное из опыта - возможно с изменением характера данных со временем стандартная статистика начнет работать нормально(но это наверное нае ваш случай). Т.е желательно в будущем периодически проверять работоспособность при нормальной статистике временно снимая блокировку.
Удачи

Имхо спорное решение - подменять статистику по реальным данным

Я не говорил, что решение тривиальное, однако считаю его вполне уместным. Цикл из 1000000 select single по ключу будет быстрее чем 1000000 фуллсканов. А .т.к Оракл о цикле не знает, то он по-своему прав. Нужно его заставить использовать индекс. Проще всего и возможно правильнее подкрутить хинт, однако это не подходит автору А здесь решение без изменения кода
К тому же с учетом индекса по единственному полю выбора статистика и смысла то особого нести не будет, какие еще варианты построения плана?