Início / dba / Perguntas / 224595
Accepted
Segfault
Asked: 2018-12-11 14:44:18 +0800 CST

Indexação para uma tabela com muitos subconjuntos grandes

  • 772

No SqlServer 2017 temos uma tabela com milhões de linhas. A tabela tem algumas dezenas de colunas. Uma das colunas é uma varchar(50)com um intervalo bem definido de valores permitidos, o valor dessa coluna é garantido como uma string de uma lista de cerca de 4.000 strings. As únicas consultas que queremos otimizar nessa tabela lidam exclusivamente com as linhas que têm apenas um desses valores, mas elas precisam recuperar todas as colunas dessas linhas. Faz sentido colocar um índice nessa coluna e, em caso afirmativo, qual tipo de índice deve ser usado?

Exemplo de esquema:

+---------------------------------------+
| Id   | Category | ... 20 other columns|
+------+----------+---------------------+
| 1    | Food     |      .....          |
+------+----------+---------------------+
| 2    | Lumber   |      .....          |
+------+----------+---------------------+

Exemplo de consulta:select * from table where Category = 'food';

Portanto, neste exemplo, a Categorycoluna contém uma string de uma lista de cerca de 4.000. Considerei um índice clusterizado, mas essa coluna não é exclusiva. Eu adicionaria um índice não clusterizado, mas a consulta pede que todas as colunas sejam retornadas, então ela precisa voltar do índice para a tabela principal para recuperar todos os dados de qualquer maneira, certo? Então temos que usar um índice de tabela completo ou existe uma opção melhor?

sql-server index

1 respostas

  1. Best Answer

    Faz sentido colocar um índice nessa coluna e, em caso afirmativo, qual tipo de índice deve ser usado?

    Não podemos responder isso para você. Depende se o desempenho da consulta é bom o suficiente sem o índice. Se o tempo de resposta do usuário final, transações por segundo, CPU geral do servidor ou qualquer métrica que seja a mais importante para você estiver bem sem o índice, você não precisará disso agora. Você pode precisar dele no futuro se a mesa ficar maior. Com tudo isso dito, a estrutura de consulta e tabela atual que você possui não fornecerá o melhor desempenho. Se for necessária uma melhoria, você tem três opções principais:

    1. Crie uma chave primária não clusterizada na idcoluna e um índice clusterizado no Category.

      Isso lhe dará o melhor desempenho possível para a consulta que você listou na pergunta. A desvantagem é que alterar o índice clusterizado pode ter impactos negativos em outras consultas. Índices clusterizados não precisam ser exclusivos. Você também não precisa de uma chave primária em sua tabela. Acabei de propor um esquema de exemplo que tinha ambos (suponho que você tenha uma chave primária hoje).

    2. Adicione um índice não clusterizado Categoryque inclua todas as outras colunas.

      Isso também lhe dará o melhor desempenho possível para a consulta que você listou na pergunta. Como desvantagem, dobrará o espaço em disco necessário para a tabela e diminuirá a velocidade das operações DML na tabela.

    3. Adicione um índice não clusterizado Categoryque não inclua todas as outras colunas.

      Isso não lhe dará o melhor desempenho possível. Ele melhorará o desempenho desde que você esteja filtrando um valor que seja seletivo o suficiente e o SQL Server opte por usar o índice. Se você precisar ajudar o otimizador, as técnicas neste post do blog do Distinguished Answerer Erik Darling podem ser úteis. Ainda há um impacto DML nessa opção, mas deve ser significativamente menor que a opção 2.

    Em última análise, a única maneira de obter uma resposta satisfatória é analisando você mesmo. Não sabemos que tipo de importância você dá ao desempenho DML, uso total do disco, desempenho de outras consultas, etc. Todas as opções que mencionei acima têm suas próprias desvantagens. Boa sorte!

    • 4

relate perguntas