AlexFF__|,

это масляное масло. применит, если сможет, а если не сможет, то откажется.
Он же сначала трансформирует запрос, если это явно не запрещено, а только потом будет разбираться с тем, что ему там знатоки хинтов понаписали.

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

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

В простых случаях все просто, и у хинтователя есть много больше прав на претензию, что он умнее оптимизатора.

А в случаях сложных соединения/агрегации множества таблиц, все может становится весьма болезненным с точки зрения
производительности, при попытках оптимизатора следовать за хинтами, по крайней мере хинтами над индексами,
чуждого ему писателя sql, и особенно, если тот писатель не вполне понимает, что делает.
Что, к сожалению, совсем нередко встречается.

реальность всегда состоит из компромиссов.
Когда у общества нет цветовой дифференциации штанов системы некачественные статистики,
межумочные объемы данных и случайное индексирование, ее поведение характеризуется как почти женское, в смысле непредсказуемости, не говоря о вероятных чудесах при обновлении версии системы.

Как-то "вчера поставил хинт, а сегодня убрал, но вчера поставил" приходится с ней общаться.
В общем, это +- околорабочее "взрослое" состояние.

Вот, кстати, говорят - "старый, что малый".
Одна из общих черт заключается в том, что малый еще не знает, что такое компромисс, а старый уже не склонен к нему.