Chaves estrangeiras de indexação do servidor SQL, abrangendo índices incluídos nas colunas

Se um FK não tiver um índice dedicado neles, mas fizer parte de índices mais amplos usados ​​para cobrir consultas, eles devem ter um índice dedicado criado?

Depende dos padrões de acesso da tabela. Se a coluna está sendo muito pesquisada (e, idealmente, é altamente seletiva), então sim, você deve ter um índice nessa coluna, com a coluna como a primeira coluna-chave na definição.

Devo remover alguns desses índices e combiná-los com colunas incluídas? então ter índices dedicados para minhas chaves estrangeiras?

O que foi dado na pergunta não está claro, e a pergunta que você fez é um pouco... confusa, então vamos dar um passo para trás por um segundo.

No SQL Server 2005+, as três partes mais importantes de uma definição de índice são:

1. As colunas de chave, que determinam a ordem de classificação do índice. Isso significa que a ordem das colunas de chave é muito importante, porque o SQL Server usa um índice procurando um valor na primeira coluna de chave, depois na segunda coluna de chave, etc.

2. As colunas incluídas, que são cópias de dados de linha marcadas na estrutura do índice. A ordem em que as colunas incluídas são especificadas é irrelevante.

3. O índice é único? Isso significa que a chave de índice pode conter apenas combinações exclusivas de valores de coluna.

(Embora isso não seja relevante para a discussão em questão, para completar, vou mencioná-lo aqui: SQL Server 2008+ apresenta o conceito de índices filtrados , que inclui apenas linhas no índice que atendem a um predicado.)

A primeira coisa que você deve fazer é a consolidação do índice. Isso envolve o uso dos pontos acima para combinar índices que compartilham pontos em comum.

Por exemplo, considere os dois índices a seguir:

CREATE INDEX IX_1 ON [dbo].[t1](C1) INCLUDE(C3, C4);
CREATE INDEX IX_2 ON [dbo].[t1](C1, C2) INCLUDE(C5);

Esses índices compartilham a coluna de chave inicial, C1. As colunas incluídas podem ser especificadas em qualquer ordem, portanto, esses dois índices podem ser combinados da seguinte maneira:

CREATE INDEX IX_3 ON [dbo].[t1](C1, C2) INCLUDE(C3, C4, C5);

Onde as chaves de índice diferem em sua composição ou outras propriedades, você deve ter muito cuidado. Considere estes índices:

CREATE INDEX IX_4 ON [dbo].[t1](C1, C3) INCLUDE(C4);
CREATE UNIQUE INDEX IX_5 ON [dbo].[t1](C1, C4) INCLUDE(C5);

Agora a decisão não é tão fácil. Você precisa determinar o que fazer com base em sua carga de trabalho, quais consultas atingem a tabela e a seletividade dos próprios dados.

Portanto, para responder à pergunta mais diretamente: se você tiver atualmente um ou mais índices em que a coluna de interesse é a primeira coluna-chave nesses índices, não será necessário adicionar mais índices, porque os índices que você possui são úteis.

Se a coluna for pesquisada com frequência e não houver um índice com essa coluna como a primeira coluna-chave, você deverá criar um índice com essa coluna como a primeira coluna-chave. (Dependendo dos requisitos da consulta, você também pode especificar outras colunas, tanto para a chave quanto para as colunas incluídas.)

Se a coluna não for pesquisada com frequência, você pode potencialmente contê-la em outro índice (não na primeira coluna-chave): a consulta pode ser satisfeita verificando o índice que contém a coluna. Isso não é tão eficiente quanto uma busca de índice (por vários motivos), mas se essa operação não acontecer com muita frequência e o desempenho nesse caso for aceitável, você pode ficar bem.

Lembre-se de que a criação de índices não é gratuita -- eles ocupam espaço de dados, espaço de log, memória cache e podem diminuir potencialmente a atividade INSERT// UPDATE( DELETEtendo dito isso, pode haver outras vantagens em criar índices). É um equilíbrio que você deve atingir para o seu ambiente.

Um índice é útil se for usado. Isso depende do tipo de consulta que você executa, como os dados são inseridos nas tabelas pai (supondo que o FK esteja ativo) e o tamanho da tabela pai. Por exemplo, se MasterAdGroupId for uma chave para a tabela MasterAdGroup e essa tabela tiver apenas 5 linhas, definir um índice sobre ela seria inútil. Além disso, a coluna chamada 'Dirty' soa como uma coluna binária e não acho que você ganharia muito ao indexá-la.

Conforme declarado em outras respostas, você deseja ter certeza de que os índices serão usados. Kevin Kline tem um bom vídeo sobre como verificar e ver quais índices estão sendo usados. Este é o código sql que ele usa para verificar índices não utilizados:

SELECT 
o.name
, indexname=i.name
, i.index_id   
, reads=user_seeks + user_scans + user_lookups   
, writes =  user_updates   
, rows = (SELECT SUM(p.rows) FROM sys.partitions p WHERE p.index_id = s.index_id AND s.object_id = p.object_id)
, CASE
    WHEN s.user_updates < 1 THEN 100
    ELSE 1.00 * (s.user_seeks + s.user_scans + s.user_lookups) / s.user_updates
  END AS reads_per_write
, 'DROP INDEX ' + QUOTENAME(i.name) 
+ ' ON ' + QUOTENAME(c.name) + '.' + QUOTENAME(OBJECT_NAME(s.object_id)) as 'drop statement'
FROM sys.dm_db_index_usage_stats s  
INNER JOIN sys.indexes i ON i.index_id = s.index_id AND s.object_id = i.object_id   
INNER JOIN sys.objects o on s.object_id = o.object_id
INNER JOIN sys.schemas c on o.schema_id = c.schema_id
WHERE OBJECTPROPERTY(s.object_id,'IsUserTable') = 1
AND s.database_id = DB_ID()   
AND i.type_desc = 'nonclustered'
AND i.is_primary_key = 0
AND i.is_unique_constraint = 0
AND (SELECT SUM(p.rows) FROM sys.partitions p WHERE p.index_id = s.index_id AND s.object_id = p.object_id) > 10000
ORDER BY reads