Devo usar muitos índices de campo único, em vez de índices específicos de várias colunas?

Esta pergunta é sobre a eficácia de uma técnica de indexação do SQL Server. Eu acho que é conhecido como "interseção de índice".

Estou trabalhando com um aplicativo existente do SQL Server (2008) que possui vários problemas de desempenho e estabilidade. Os desenvolvedores fizeram algumas coisas estranhas com a indexação. Não fui capaz de obter referências conclusivas sobre essas questões, nem posso encontrar uma documentação realmente boa sobre os internets.

Existem muitas colunas pesquisáveis ​​em uma tabela. Os desenvolvedores criaram um índice de coluna única em CADA das colunas pesquisáveis. A teoria era que o SQL Server seria capaz de combinar (cruzar) cada um desses índices para acessar com eficiência a tabela na maioria das circunstâncias. Aqui está um exemplo simplificado (a tabela real possui mais campos):

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

Acho que vários índices de coluna direcionados aos critérios de pesquisa são muito melhores, mas posso estar errado. Vi planos de consulta que mostram o SQL Server fazendo uma correspondência de hash em duas pesquisas de índice. Talvez isso faça sentido quando você não sabe como a tabela é pesquisada? Obrigado.

O que você precisa está cobrindo índices, ou seja. índices que podem satisfazer uma consulta por conta própria. Mas um índice de 'cobertura' tem um problema: está cobrindo uma consulta específica . Portanto, para desenvolver uma boa estratégia de indexação, você precisa entender sua carga de trabalho: quais consultas estão atingindo o banco de dados, quais são críticas e quais não são, com que frequência cada tipo de consulta é executada, etc etc etc. E então você compare isso com o custo de gravação e atualização de cada índice, e aí está sua estratégia de indexação. Se parece complicado, é porque é complicado.

No entanto, você pode aplicar algumas regras práticas. O MSDN cobre muito bem o básico:

• Noções básicas de design de índice
• Diretrizes gerais de design de índice
• Diretrizes de Design de Índice em Cluster
• Diretrizes de design de índice não clusterizado

Há também uma infinidade de artigos contribuídos pela comunidade, por exemplo. Gravação de Webcast - DBA Darwin Awards: Index Edition .

E para responder sua pergunta especificamente: índices separados em cada coluna podem funcionar, desde que cada coluna tenha uma alta seletividade (muitos valores distintos, cada um deles aparecendo apenas algumas vezes no banco de dados). O plano de acesso resultante usando junção de hash entre duas varreduras de intervalo de índice geralmente funciona muito bem. As colunas com baixa seletividade (poucos valores distintos, cada valor aparecendo muitas vezes no banco de dados) não fazem sentido para serem indexadas por si próprias, o otimizador de consulta simplesmente as ignora. No entanto, muitas vezes as colunas de baixa seletividade são boas chaves compostas quando emparelhadas com uma coluna de alta seletividade.