Início / dba / Perguntas / 139749
Accepted
sebeid
Asked: 2016-05-28 07:54:08 +0800 CST

Índice composto

  • 772

Supondo que eu tenha uma tabela X com 12 colunas. Em minhas consultas, estou filtrando essas condições:

select * from x where a=@a and b=@b

select *  from x where a=@b and b=@b and c=@c

select * from x  where a=@b and b=@b and d=@d

select * from x where a=@b and b=@b and e=@e

Esta tabela é uma tabela muito ativa e preciso evitar o bloqueio. Se eu precisar criar índices nesta tabela, devo criar 4 índices como este:

 (a,b) (include columns) 

 (a,b,c) (include columns) 

 (a,b,d) (include columns) 

 (a,b,e) (include columns)

Ou assim:

(a,b) (include columns)

(c)

(d)

(e)

Ou crie 1 índice (a,b,c,d,e) (inclua colunas)

Estas são as contagens de valores distintos para cada coluna. linhas totais 1446631, a = 366279, b= 96, c = 6, e = 2, d= 11098

sql-server index

2 respostas

  1. Best Answer

    Se todos os seus padrões de consulta incluírem filtros em ae b, e a tabela for muito gravada, sugiro testar um único índice que se pareça com este:

    (a,b) include (c,d,e,other include columns)

    O motivo é que é necessário manter um único índice em vez de três ou quatro, e a seletividade da terceira coluna no filtro provavelmente não adicionará muitos benefícios adicionais às consultas individuais, pois as duas primeiras colunas já filtram a maior parte da tabela (bem , na verdade, a primeira coluna, já que a segunda coluna tem poucos valores distintos). Você pode monitorar as consultas e ver se algum padrão ou valor de parâmetro específico leva a estimativas terrivelmente ruins, tempos de execução longos ou avisos de índice ausentes. Suspeito que não porque, novamente, com base na densidade que você citou, isso deve levar a intervalos muito pequenos, desde que suas consultas usem filtros em a e b ou, no mínimo, a.

    Vou enfatizar que onde você vai acabar não será uma resposta simples "oh, isso é claramente o que você deve fazer". Você precisará testar seu hardware, seus dados e seus padrões de consulta (leitura e gravação) para determinar o(s) melhor(es) índice(s) para sua carga de trabalho.

    • 9

  2. Como em todas as coisas, depende. Especificamente sobre a cardinalidade das colunas. Se a combinação de colunas ae bfor única, você realmente só precisa de um índice (a,b). Se estiver próximo (digamos <100 linhas cada), você provavelmente ficará bem. Por outro lado, digamos que ctenha alta cardinalidade (grande número de valores possíveis) e dbaixa cardinalidade (baixo número de valores possíveis). Você pode criar apenas criar (a,b,c). Isso cobrirá a consulta específica usando a, be c. Ele também cobrirá com a mesma facilidade uma consulta usando apenas ae b. E para a, be dchegará perto. O SQL se aproximará usando aebe, em seguida, pode verificar as linhas restantes, uma vez que dnão será de muita ajuda de qualquer maneira.

    Todas as coisas sendo iguais e assumindo uma cardinalidade razoável de cada uma, eu criaria o seguinte.

    (a,b,c) (include columns) 

(a,b,d) (include columns) 

(a,b,e) (include columns)

    A consulta usando apenas ae bserá coberta pelas demais. Supondo que todas as outras colunas sejam cobertas nas colunas de inclusão, é claro.

    • 2

relate perguntas