Início / dba / Perguntas / 54059
Accepted
paulH
Asked: 2013-11-28 10:19:05 +0800 CST

Um índice ou dois?

  • 772

Eu tenho o seguinte índice criado em uma tabela no meu banco de dados:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

O servidor está sugerindo o seguinte índice 'ausente':

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

Parece-me lógico alterar a definição de índice existente para incluir as colunas sugeridas, em vez de criar um novo índice que precisa ser mantido. Uma consulta que seleciona em col1 e col2 pode usar index1 com a mesma eficiência que index2. Estou correto ou talvez esteja faltando alguma coisa?

sql-server sql-server-2008-r2

3 respostas

  1. Best Answer

    E assim entra a arte de ajustar o desempenho e estratégias de indexação...

    Parece-me lógico alterar a definição de índice existente para incluir as colunas sugeridas

    Vou pegar sua citação e escrever uma terceira definição de índice:

    create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

    Essa deve ser a CREATE INDEXdeclaração que corresponde à sua declaração citada.

    Isso pode muito bem ser uma solução prudente, mas depende . Aqui estão alguns exemplos quando digo que depende.

    Se você tiver uma carga de trabalho comum que consiste principalmente em consultas como esta:

    select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

    Então seu idx_index1índice seria sólido. Perfeitamente estreito, é um índice que satisfaz essa consulta sem dados estranhos (sem levar em consideração a definição de índice clusterizado, se houver).

    Mas se você tiver uma carga de trabalho que consiste principalmente em consultas como as seguintes:

    select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

    idx_index2Seria sensato, pois é o que chamamos de índice de cobertura , evitando a necessidade de uma pesquisa de chave de volta ao índice clusterizado (ou uma pesquisa de RID de volta ao heap). Essa definição de índice não clusterizado abrangeria apenas todos os dados necessários à consulta.

    Com sua recomendação, seria adequado para uma consulta como a seguinte:

    select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

    Sua idx_index3recomendação seria um índice de cobertura que satisfaça os critérios de pesquisa para a consulta acima.

    O ponto que estou tentando chegar é que, em uma questão isolada como essa, não podemos responder definitivamente. Tudo depende de qual é a carga de trabalho comum e frequente. Claro que você sempre pode definir todos esses três índices para lidar com cada tipo de consulta de amostra, mas então entra em questão a manutenção que será necessária para manter esses índices atualizados (pense: INSERTs, UPDATEs, DELETEs). Essa é a sobrecarga dos índices.

    Você precisa dissecar e avaliar a carga de trabalho e determinar onde as vantagens serão melhores. Se a primeira consulta de amostra for a mais comum, de longe, sendo executada dezenas de vezes por segundo, e houver uma consulta muito pouco frequente como a terceira consulta de amostra, não faria sentido inchar as páginas de nível folha do índice com o INCLUDEcolunas não-chave. Tudo depende da sua carga de trabalho.

    Se você entender estratégias de indexação prudentes e entender sua carga de trabalho comum, então, aplicando ambos, você será capaz de descobrir qual é o melhor caminho a seguir.

    • 12

  2. Você está realmente correto e descobriu por que é importante para um DBA sempre revisar as "sugestões" apresentadas pelos DMVs de índice ausente etc.

    Considere que as sugestões oferecidas pelos DMVs de índice ausente são apresentadas isoladamente, o que significa que o SQL Server decidiu que um índice da estrutura recomendada beneficiaria a consulta, independentemente de quais outras estruturas de índice já existam.

    • 7

  3. Um pouco mais, sobre uma das implicações da resposta de Thomas:

    Ele disse:

    Claro que você sempre pode definir todos esses três índices para lidar com cada tipo de consulta de amostra, mas então entra em questão a manutenção que será necessária para manter esses índices atualizados (pense: INSERTs, UPDATEs, DELETEs). Essa é a sobrecarga dos índices.

    Então, outra grande questão se torna: com que frequência a tabela é atualizada?

    Considere primeiro um exemplo de uma tabela que é atualizada constantementeORDERS , como por exemplo, uma tabela de varejo refletindo a atividade do consumidor do site... afetam constantemente o desempenho do banco de dados.

    Por outro lado, considere uma tabela que é atualizada apenas como parte da configuração do site - a tabela sendo atualizada UMA VEZ para a maioria dos valores e os valores adicionados com pouca frequência - aí, lentidões de atualização praticamente não são consideradas. Múltiplos índices podem retardar as reconstruções e reorganizações de índices de banco de dados, mas desde que sejam rápidos o suficiente, SINTA-SE LIVRE: se vários índices aceleram as leituras, vá em frente.

    Um caso intermediário pode ser uma tabela que normalmente só é atualizada em um processo em lote durante a noite. Lá, as lentidões de atualização de vários índices não afetariam o desempenho diurno - elas afetariam apenas (1) o tempo gasto para executar a manutenção noturna do lote, (2) o desempenho de quaisquer processos simultâneos e (3) o tempo gasto para tarefas de manutenção de banco de dados como reorganização de índices. Portanto, desde que os processos nessas 3 arenas estejam sendo executados rápido o suficiente para você... crie os índices que aceleram as consultas.

    HTH...

    • 3

relate perguntas