[fed]

Ладно, я тут еще немножко теории добавлю:
Во первых - уникальный индекс всегда чуть меньше нагружает SQL Server чем не уникальный:
1. Не надо хранить гистограмму в статистике индекса, поскольку заведомо известно что по данному условию (скажем - inventTransId+journalid+lineId) всегда найдется только одна запись.
2. Уникальные индексы чуть быстрее обновляются, поскольку, опять таки, при удалении/обновлении записи не надо перебирать n-индексных входов в поисках того, который надо удалить.
Во вторых - начиная с DAX2009, система поддерживает кэширование по нескольким уникальным ключам. То есть, в памяти храниться кэш записей и отдельно болтается НЕСКОЛЬКО B-Tree (а может и хэшей - не знаю), в которых хранятся значения разных уникальных ключей. Так что работа с уникальными индексами позволяет экономить ресурсы не только сервера БД, но и сервера AOS.(NB - в 4ке и более ранних версиях, кэширование работало только для индекса, указанного как primary index таблицы).
В третьих, хочу напомнить что индексы используются не только для поиска, но и для сортировки. И если запрос не очень сложный, а индекс подходящий, то order by/group by может быть выполнено без дополнительных сортировок, за счет использования готового индекса. (Хотя это явно не случай ProdJournalBOM).
Ну и наконец хочу напомнить о таком понятии, как покрывающий индекс. Если все поля в запросе, находятся в неком индексе, система может выполнить запрос без необходимости чтения из таблицы. Например запрос select journalId from prodBOMJournal where prodBOMJournal.inventTransId==_inventTransId будет выполнен с помощью одиночного поиска по индексу transIdIdx, без чтения данных из таблицы.