Задался вот каким вопросом. Зачем unique constraint на таблице требует обязательного наличия индекса, уникального или нет, по всем полям, входящим в уникальный ключ?
Сама вариативность уникальный/неуникальный индекс наводит на мысль, что индекс как таковой используется только для быстрого поиска строк для блокировки.
У меня периодически возникает желание сделать уникальный ключ по индексу, включающему в себя только часть полей. Например, ключ состоит из колонок a1 .. a6, причем a1,a2 дает селективность в ~ 10 строк. Индекс по ним будет размером куда меньше, нежели индекс по всем 6 полям, а для цели отобрать и заблокировать до окончания транзакции строки его вполне достаточно.

Документацию в плане как есть? Я это знаю. Документацию в плане почему так? Вот это не встречал. Дайте ссылку, если не затруднит?

Ссылки тем не менее не последовало.
Поясните, что именно считаете бредом и почему?

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

Но тем не менее, из ссылки не вытекает ничего, что объяснило бы, зачем индексу все поля ключа.

Например, для обеспечения целостности на внешних ключах без индекса производится блокировка всей таблицы.

Внешний ключ как пример того, что может выполняться лок + фуллскан. И заявление типа "это плохо" - не катит, потому что бывают разные ситуации.

Я просто хочу прояснить для себя, почему логика именно такова. Чисто академический интерес, не более.

Если эта таблица модифицируется только одной сессией в принципе, то все блокировки меня мало волнуют. Индексы на чтение далеко не всегда совпадают с индексами на модификацию для устранения фуллсканов. Ну и т.д. Ситуации бывают, когда полный лок таблицы не есть плохо. И не надо тут рассказывать свое понимание того, как базе работать будет лучше.

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

Ну так я его и не использую :)

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

Хочу я сформулировал по-моему четко: понять, почему принципиально нельзя подсунуть "частичный индекс" под уникальный ключ, чем собственно он принципиально отличается от неуникального индекса.
И попутно еще родился вопрос - а зачем собственно есть возможность использовать неуникальный индекс? В каких случаях это может быть востребовано, за исключением очевидных "был старый неуникальный индекс, логика поменялась, навесили констрейнт, и не хотим делать новый/пересоздавать старый индекс.