Se eu fizer uma uniquerestrição em um campo, também preciso fazer um índice nesse campo para obter um tempo de inserção escalável? Ou isso é feito para mim (mesmo que o índice usado não seja acessível publicamente?)
Especificamente, estou trabalhando com o Apache Derby para prototipagem, embora provavelmente vá movê-lo para o MySQL em um futuro próximo. Também espero que haja algo no padrão SQL que diga algo sobre isso.
Nunca terei necessidade de pesquisar por este campo, então prefiro não fazer um índice inútil. Mas prefiro ter um índice inútil do que um O(n)tempo de inserção.
CHAVE PRIMÁRIA >= ÚNICA >= ÍNDICE == CHAVE
Os dados do InnoDB são ordenados pela PK. MyISAM PK age da mesma forma que UNIQUE.
INSERT deve adicionar uma "linha" a todo e qualquer índice (de qualquer tipo) que você tenha. Isso leva algum tempo. (Geralmente não há tempo suficiente para importar.) Os índices são todos armazenados no formato BTree. Os blocos MyISAM BTree têm 1 KB; InnoDB usa 16 KB.
A inserção no InnoDB atualiza o PK e os dados simultaneamente.
Inserir no MyISAM geralmente "anexa" os dados ao .MYD. Separadamente, adiciona uma linha ao PK (se houver).
INSERT precisa primeiro verificar se não há chave duplicada para qualquer chave PRIMÁRIA ou UNIQUE. Isso é feito usando o índice. E, portanto, por que as CONSTRAINTS UNIQUE e FOREIGN KEY realmente constroem índices. Isso é O(logN), mas geralmente CPU, não E/S, porque é um cache eficiente.
--EDITAR--
Minha resposta original (abaixo) provavelmente não é útil para você porque não aborda a questão das
uniquerestrições. Como outros já disseram, essas restrições geralmente são implementadas com um índice exclusivo implícito. Em casos especiais, isso pode não ser verdade (por exemplodisable novalidate, para Oracle).A pergunta poderia ser: é possível impor exclusividade sem um índice? De um modo geral, a resposta é não, embora em alguns casos um índice agrupado signifique que o índice e a tabela são o mesmo objeto.
--FIM DA EDIÇÃO--
Você disse "Prefiro ter um índice inútil do que ter um tempo de inserção O(n).", mas, em geral, os bancos de dados não têm tempo de inserção O(n). Existem dois casos a considerar:
Uma tabela normal com ou sem índices:
Novas linhas são despejadas no topo da pilha. O RDBMS provavelmente examina apenas 1 bloco, portanto, não apenas O(1), mas O(1) muito pequeno.
Se a tabela tiver índices, um ponteiro para a linha será adicionado a cada um. Isso geralmente será uma operação O(log(n)).
Uma tabela com algum tipo de agrupamento acontecendo, por exemplo, uma tabela organizada por índice ou cluster para Oracle, ou um índice agrupado para SQL Server e outros:
Novas linhas são inseridas em um bloco específico, o que pode fazer com que o bloco se divida ou transborde, mas, aconteça o que acontecer, ainda é O(log(n)) ou melhor , causado pela b-tree ou estrutura semelhante usada para encontrar o bloco.
Para responder à pergunta em negrito: Sim, tornar um campo exclusivo o indexa como uma chave primária. Na verdade, eu havia discutido isso em outra pergunta em relação às chaves primárias com seu próprio nome para distingui-las de outras chaves exclusivas (candidatas) .
Quanto às restrições, os índices são criados para você para que o paradigma de restrição seja configurado. Você deve ser capaz de remover índices duplicados, até mesmo chaves UNIQUE, desde que a restrição que você fez não faça referência a outras chaves UNIQUE que você criou pessoalmente além do paradigma de restrição.
Você pode nunca ter que procurar por este campo, mas o MySQL com certeza terá como seu caminho para determinar a validade das chaves e determinar como executar as operações ON DELETE CASCADE e ON UPDATE CASCADE.
O índice UNIQUE simplesmente garante a unicidade de tuplas (singletons, pares, trios, ..., n-tuplas, etc) em cada linha da tabela.
Fica a seu critério remover esses índices duplicados, desde que você não quebre o paradigma de restrição que deseja que a tabela tenha.