Uma chave estrangeira cria automaticamente um índice?

Foi-me dito que, se eu digitar duas tabelas com chave estrangeira, o SQL Server criará algo semelhante a um índice na tabela filho. Eu acho difícil acreditar que isso seja verdade, mas não consigo encontrar muita coisa relacionada especificamente a isso.

Meu verdadeiro motivo para perguntar isso é porque estamos com um tempo de resposta muito lento em uma instrução delete contra uma tabela que provavelmente possui 15 tabelas relacionadas. Perguntei ao nosso cara do banco de dados e ele diz que, se houver uma chave estrangeira nos campos, ela funcionará como um índice. Qual a sua experiência com isso? Devo adicionar índices em todos os campos de chave estrangeira ou eles são uma sobrecarga desnecessária?

Uma chave estrangeira é uma restrição, um relacionamento entre duas tabelas - que nada tem a ver com um índice em si.

Mas é um fato conhecido que faz muito sentido indexar todas as colunas que fazem parte de qualquer relacionamento de chave estrangeira, porque, por meio de um relacionamento FK, você muitas vezes precisará procurar uma tabela relacionada e extrair determinadas linhas com base em um único valor ou um intervalo de valores.

Portanto, faz sentido indexar qualquer coluna envolvida em um FK, mas um FK em si não é um índice.

Confira o excelente artigo de Kimberly Tripp "Quando o SQL Server parou de colocar índices nas colunas de chave estrangeira?" .

Uau, as respostas estão por todo o mapa. Então a documentação diz:

Uma restrição FOREIGN KEY é candidata a um índice porque:

• As alterações nas restrições PRIMARY KEY são verificadas com as restrições FOREIGN KEY nas tabelas relacionadas.

• As colunas de chave estrangeira são frequentemente usadas nos critérios de junção quando os dados das tabelas relacionadas são combinados nas consultas, correspondendo as colunas na restrição FOREIGN KEY de uma tabela com as colunas de chave primária ou exclusiva na outra tabela. Um índice permite que o Microsoft® SQL Server ™ 2000 encontre dados relacionados na tabela de chaves estrangeiras rapidamente. No entanto, a criação deste índice não é um requisito. Os dados de duas tabelas relacionadas podem ser combinados, mesmo que nenhuma restrição PRIMARY KEY ou FOREIGN KEY seja definida entre as tabelas, mas um relacionamento de chave estrangeira entre duas tabelas indica que as duas tabelas foram otimizadas para serem combinadas em uma consulta que usa as chaves como seus critérios.

Portanto, parece bastante claro (embora a documentação esteja um pouco confusa) que na verdade não cria um índice.

Não, não há índice implícito nos campos de chave estrangeira; caso contrário, por que a Microsoft diria "Criar um índice em uma chave estrangeira é geralmente útil" . Seu colega pode ser confuso o campo de chave estrangeira na tabela referindo com a chave primária nos referidos-to table - chaves primárias não criar um índice implícito.

O SQL Server cria automaticamente índices para Chaves Primárias, mas não para Chaves Estrangeiras. Crie o índice para as chaves estrangeiras. Provavelmente vale a pena.

Digamos que você tenha uma grande mesa chamada pedidos e uma pequena mesa chamada clientes. Há uma chave estrangeira de um pedido para um cliente. Agora, se você excluir um cliente, o Sql Server deverá verificar se não há pedidos órfãos; se houver, isso gera um erro.

Para verificar se há algum pedido, o Sql Server precisa pesquisar na tabela de grandes pedidos. Agora, se houver um índice, a pesquisa será rápida; se não houver, a pesquisa será lenta.

Portanto, nesse caso, a exclusão lenta pode ser explicada pela ausência de um índice. Especialmente se o Sql Server tiver que pesquisar 15 tabelas grandes sem um índice.

PS Se a chave estrangeira tiver ON DELETE CASCADE, o Sql Server ainda precisará pesquisar a tabela de pedidos, mas remover os pedidos que façam referência ao cliente excluído.

Chaves estrangeiras não criam índices. Somente restrições de chave alternativas (UNIQUE) e restrições de chave primária criam índices. Isso é verdade no Oracle e SQL Server.

Não que eu saiba. Uma chave estrangeira apenas adiciona uma restrição de que o valor na chave filha também seja representado em algum lugar da coluna pai. Não está dizendo ao banco de dados que a chave filha também precisa ser indexada, apenas restrita.

A rigor, chaves estrangeiras não têm absolutamente nada a ver com índices, sim. Mas, como os oradores acima de mim apontaram, faz sentido criar um para acelerar as pesquisas de FK. De fato, no MySQL, se você não especificar um índice na sua declaração FK, o mecanismo (InnoDB) o cria automaticamente para você.

No PostgeSql, você pode verificar se há índices se clicar em \ d tablename

Você verá que os índices btree foram criados automaticamente em colunas com chave primária e restrições exclusivas, mas não em colunas com chaves estrangeiras.

Eu acho que isso responde à sua pergunta pelo menos para o postgres.

Percebo que o Entity Framework 6.1 apontado para o MSSQL adiciona automaticamente índices em chaves estrangeiras.

O InnoDB requer índices em chaves estrangeiras e chaves referenciadas para que as verificações de chaves estrangeiras possam ser rápidas e não exigir uma varredura de tabela. Na tabela de referência, deve haver um índice em que as colunas de chave estrangeira sejam listadas como as primeiras colunas na mesma ordem.