Есть табличка 10-ки млн записей.
Делаем запрос:


В индекс documents_i создан по (id, doc_date).
В таблице есть еще куча объемных полей.
Плюс индекс уже как бы отсортирован, но при этом оракл показывает, что хочет фулсканить таблицу, а не индекс.
При этом понятно, что ему придется прочитать гораздо больше блоков с диска, чем, если бы он читал индекс.
Больше того, на аналогичной таблице такого же плана запрос фулсканит индекс, хотя в той таблице нет ни PK по ID, ни NOT NULL ограничения на ID (так же как и на documents).

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

ORA__SQLid и/или doc_date nullable
Да, как уже сказал, id nullable, хотя по факту не имеет пустых значений.
Попробую создать констрейнт,
но интересно, почему на аналогичных таблицах (где Id тоже nullable) такой же запрос сканит индекс, а не таблицу?

ElicВключи мозг.
Было бы что включать )
Так и что, что order by 1, пишу

Ничего не меняется :( Может и туплю конечно.
И потом, говорю же, - такой же запрос на других аналогичных таблицах работает по индексу.
andrey_anonymousПотому что предикат.
Без предиката тоже пробовал и на таблицах, и опять же на таблицах, где работа по индексу без предиката что с предикатом, что без индекс подхватывается.
Пока остается только констрейнт добавить, потом глянуть.

авторЕсли я правильно понял, утверждается что есть ситуация, в которой:
- индекс содержит только nullable поля
- в запросе нет предикатов, позволяющих оптимизатору понять, что null-значения не нужны
- индекс подхватился
Пример в студию.
Фух, уже расстроился, что за чудеса такие, оказалось, в упор не заметил, все верно - где индекс подхватывается ID все-таки не nullable. Вопрос снят, сори.
Elic, спасибо, но по ссылке, так и не понял что может быть не так с order by 1 :( (мне же тут как бы и не важна сортировка)

ElicДа ну?
То есть не важно какую запись из окна дублей по ID надо забрать.