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 tem vários problemas de desempenho e estabilidade. Os desenvolvedores fizeram algumas coisas estranhas com a indexação. Não consegui obter benchmarks conclusivos sobre essas questões, nem encontrei nenhuma documentação realmente boa na internet.
Há muitas colunas pesquisáveis em uma tabela. Os desenvolvedores criaram um índice de coluna única em CADA uma das colunas pesquisáveis. A teoria era que o SQL Server seria capaz de combinar (interseccionar) cada um desses índices para acessar a tabela com eficiência na maioria das circunstâncias. Aqui está um exemplo simplificado (a tabela real tem 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. Eu vi planos de consulta que mostram o SQL Server fazendo uma correspondência de hash em duas buscas de índice. Talvez isso faça sentido quando você não sabe como a tabela é pesquisada? Obrigado.
O que você precisa são índices de cobertura , 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. equilibre isso com o custo de gravação e atualização de cada índice, e aí você tem sua estratégia de indexação. Se parece complicado é porque é complicado.
No entanto, você pode aplicar algumas regras práticas. O MSDN cobre o básico muito bem:
Há também uma infinidade de artigos contribuídos pela comunidade, por exemplo. Gravação de Webcast – DBA Darwin Awards: Edição de Índice .
E para responder especificamente à sua pergunta: índices separados em cada coluna podem funcionar, desde que cada coluna tenha uma alta seletividade (muitos valores distintos, cada valor aparecendo apenas algumas vezes no banco de dados). O plano de acesso resultante usando hash join entre duas varreduras de intervalo de índice geralmente funciona muito bem. Colunas com baixa seletividade (poucos valores distintos, cada valor aparecendo muitas vezes no banco de dados) não fazem sentido para serem indexadas por conta própria, o otimizador de consultas simplesmente as ignorará. No entanto, colunas de baixa seletividade muitas vezes são boas chaves compostas quando combinadas com uma coluna de alta seletividade.