Akinasphinx_mvЭто ничего, что ключи к запросам не имеют вообще никакого отношения?
Ключ имеет отношение сугубо к структуре данных, а именно - для идентификации записи в таблице. Собственно, и все.
Ух ты, а мужики-то не знают! и мучаются, подбирают комбинации индексов такие, чтобы при минимальном их количестве/объёме получить максимальное ускорение работы запросов... да, любой запрос работает и без ключей, но порою настолько медленно и печально, что наличие индекса является просто жизненной необходимостью.

Ключ, когда он первичный - это индекс, обладающий парой дополнительных особенностей. Он гарантированно UNIQUE, и емнип гарантированно NOT NULL. На некоторых СУБД/engine он ещё и обязательно кластерный, но вот это уже не абсолют. На некоторых СУБД подсистема контроля целостности требует, чтобы индекс на стороне "один" внешней связи был первичным - но тоже не абсолют.
А когда НЕ первичный, то понятия "ключ" и "индекс" - синонимы.
Не надо в кучу мешать теорию и реализацию. Ключи это элемент теории реляционной БД. Индексов вообще нет в теории - это способ реализации этой теории. Если теория требует что значения ключа должны быть уникальны, то как это технически реализовать без использования уникального индекса? Наверно можно, но будет жутко тормозить.
Весь гимор с комбинированием индексов только потому что ничего лучше не придумали для реализации теории.

eNoseDima TЕсли теория требует что значения ключа должны быть уникальны, то как это технически реализовать без использования уникального индекса? селект каунт.
если ноль - то делать вставку, иначе ошибка.

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

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

Akinaв то время как для первичного ключа новое значение будет браться из служебной статистики для данной таблицы (именно поэтому при генерации первичный ключ-автоинкремент запросто продуцирует "дыры" в последовательности значений). То есть замедление - организационное, а не алгоритмическое.
Тут без проверки уникальности все равно никуда: значение счетчика принудительно можно сдвинуть, и пойдет он те же значения выдавать. Или просто разрядность маленькая, круг пройдет и снова с 1 начнет.
На автоинкременте жизнь не заканчивается. Есть ГУИДы. Ключ не обязательно должен быть абстрактным, например серия-номер паспорта.

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

О чем вообще спорим? Я просто указал на кашу из понятий. Просто не надо делать утверждений что теплое всегда мягкое.

AkinaDima TКлюч не обязательно должен быть абстрактным, например серия-номер паспорта.В этом случае натуральный ключ МОЖЕТ быть первичным. Но делать его первичным более чем неразумно - особенно если он потребуется использовать его для связи таблиц. Синтетический предпочтительнее в подавляющем большинстве случаев.
Не спорю. С натуральными на практике много казусов бывает. Я просто для примера написал.