Tenho uma tabela com 150 milhões de registros e 8 índices. Um dos índices está ativado userId. Muitas das consultas atuais são filtradas userIde, portanto, esse índice funciona perfeitamente. Para uma das consultas, tenho que expandir a cláusula where para incluir colunas regionIde . productIdTenho duas opções: posso criar um novo índice com (userId, regionId, productId)ou adicionar essas novas colunas ao índice existente. Qual seria uma opção melhor? Se eu modificar o índice existente, isso afetará as outras consultas que já usam userId?
Meu objetivo:
quero que minha consulta atual que expande a cláusula where seja incluída RegionIde productIdexecutada mais rapidamente, mas não quero que minhas outras consultas que tenham apenas userIda cláusula where sejam afetadas. Se eu adicionar um novo índice, (userid, regional, productid)posso fazer isso, mas não tenho certeza se estou duplicando o índice, pois já tenho um índice existente no userIdqual posso expandir para incluir regionide productId. Mas não tenho certeza sobre as consequências de modificar o índice existente.
Obrigado pelo seu tempo!
Supondo que sua consulta filtre
RegionIdeProductIdtambém filtreUserIdno mesmo conjunto de predicados, sim, você pode melhorar essas consultas definindo seu índice não clusterizado como(UserId, RegionId, ProductId).Qualquer alteração de índice em seu banco de dados pode afetar as consultas existentes. Mesmo que você já tenha um índice apenas
(UserId)que suas consultas estão usando no momento, não há garantia de que eles não mudarão para usar o índice em(UserId, RegionId, ProductId), mesmo como um novo índice separado.Sim, você provavelmente criaria uma redundância sem nenhum benefício real. É um caso extremo quando há um cenário para índices redundantes, como o que você está propondo. Além disso, você cria mais sobrecarga quando a tabela é
INSERTed,UPDATEed ouDELETEd desde porque mais índices precisam ser mantidos para essas alterações DML. Em geral, seria melhor expandir a definição do índice existente.A única maneira de descobrir é testando. Você pode salvar a definição de índice original e colocá-la de volta como estava, caso tenha problemas. Você também pode desabilitar índices clicando com o botão direito do mouse neles no SSMS e clicando em
Disableou via T-SQL, por exemplo:ALTER INDEX IndexName ON SchemaName.TableName DISABLE;.Geralmente, é uma boa estratégia criar o mínimo de índices necessário que cubra o maior número possível de consultas. E, novamente, os casos em que índices redundantes são necessários são muito poucos e distantes entre si, então é provável que você se saia bem descartando o índice antigo apenas
(UserId)e substituindo-o pelo índice melhor definido em(UserId, RegionId, ProductId).Mas é claro que muito disso é adivinhação sem saber os predicados exatos de todas as suas consultas envolvidas. Geralmente, você deve adicionar algumas das consultas relevantes às suas postagens, juntamente com a tabela completa e as definições de índice existentes, ao fazer perguntas sobre desempenho aqui.
Por exemplo, se as consultas que você está tentando melhorar usam uma pesquisa de desigualdade,
UserIdentão seu índice proposto provavelmente não seria útil para essas consultas de qualquer maneira, e um índice separado apenas(RegionId, ProductId)(deixando o índice original sozinhoUserId) pode ser o melhor responder. Isso realmente depende das especificidades do que suas consultas estão fazendo.