Não tenho certeza se devo usar índices não clusterizados corretamente. O estimador de plano do SSMS disse para adicionar outro índice quando o seguinte índice já estava na tabela.
CREATE NONCLUSTERED INDEX [ix_zone_fetch_shipping] ON [dbo].[tbl_shipping_rates_zones]
(
[iso] ASC, [mzone] ASC, [postal] ASC
)
INCLUDE
(
[region], [zone_dom], [zone_emi], [zone_pmi], [zone_fci],
[zone_ups], [zone_fed]
)
minha consulta foi
SELECT * FROM tbl_shipping_rates_zones WHERE postal = '10001'
Minha pergunta é... devo criar um índice para todas as chaves de pesquisa possíveis? Pesquiso por mzone, iso e postal em diferentes consultas.
Obrigado
O SQL Server mostrará um índice que gostaria de usar, pois estima que esse índice facilitaria a vida. Certamente não há necessidade de criar um índice em cada campo pesquisável; na verdade, isso tornará o desempenho de gravação substancialmente pior. Se você tiver menos de 5 a 10 índices na tabela fornecida e executar essa consulta o tempo todo, provavelmente desejará adicionar o índice sugerido exatamente como o SSMS mostra.
Edição do JNK abaixo
Também é importante examinar os índices sugeridos juntos. As sugestões estão todas em silos, por assim dizer, então todo um índice sugerido pode ser substituído pela adição de um
INCULDE
campo d em outro índice.Por exemplo, é possível ter sugestões para estes dois índices:
Quando na verdade você poderia atender as necessidades de ambos com:
Já vi isso com índices muito mais complicados (10-20 campos-chave, 10-20 campos incluídos) em que adicionar um campo à
INCLUDE
lista eliminará a necessidade do segundo índice.A razão pela qual ele está dizendo para você criar um novo índice é porque o que você tem não é o melhor possível. O otimizador de consulta é bastante seletivo na forma como escolhe qual índice usar, o link a seguir deve ajudá-lo a entender a seletividade:
< Link >
Você disse acima que incluiu todas as colunas no índice - basicamente duplicando os dados da tabela. Com base nisso, qual seria o problema em criar 3 índices separados nas colunas que você mencionou? O espaço utilizado seria menor e a velocidade seria muito maior. Eu arriscaria um palpite de que é isso que o DTA/plano de execução está lhe dizendo - apenas de uma maneira diferente.
Veja os detalhes do plano de execução que são gerados pela consulta para identificar onde estão seus gargalos e use isso como uma diretriz sobre como projetar seus índices. O SQL Server é muito bom em saber o que é melhor - confie no que ele está dizendo.
Espero que isso ajude você.