¿Debo usar muchos índices de campo único, en lugar de índices específicos de varias columnas?

Esta pregunta trata sobre la efectividad de una técnica de indexación de SQL Server. Creo que se conoce como "intersección de índice".

Estoy trabajando con una aplicación existente de SQL Server (2008) que tiene una serie de problemas de rendimiento y estabilidad. Los desarrolladores hicieron algunas cosas extrañas con la indexación. No he podido obtener puntos de referencia concluyentes sobre estos temas, ni puedo encontrar ninguna documentación realmente buena en Internet.

Hay muchas columnas de búsqueda en una tabla. Los desarrolladores crearon un índice de una sola columna en CADA una de las columnas de búsqueda. La teoría era que SQL Server podría combinar (intersectar) cada uno de estos índices para acceder de manera eficiente a la tabla en la mayoría de las circunstancias. Aquí hay un ejemplo simplificado (la tabla real tiene más 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

Creo que los índices de múltiples columnas dirigidos a criterios de búsqueda son mucho mejores, pero puedo estar equivocado. He visto planes de consulta que muestran que SQL Server hace una coincidencia hash en dos búsquedas de índice. ¿Quizás esto tiene sentido cuando no sabes cómo se busca en la tabla? Gracias.

Lo que necesita son índices de cobertura , es decir. índices que pueden satisfacer una consulta por sí mismos. Pero un índice de 'cobertura' tiene un problema: está cubriendo una consulta específica . Entonces, para desarrollar una buena estrategia de indexación, debe comprender su carga de trabajo: qué consultas están llegando a la base de datos, cuáles son críticas y cuáles no, con qué frecuencia se ejecuta cada tipo de consulta, etc., etc. Y luego equilibre esto con el costo de escritura y actualización de cada índice, y ahí tiene su estrategia de indexación. Si suena complicado, es porque es complicado.

Sin embargo, puede aplicar algunas reglas generales. El MSDN cubre los conceptos básicos bastante bien:

• Conceptos básicos de diseño de índices
• Pautas generales de diseño del índice
• Pautas de diseño de índice agrupado
• Pautas de diseño de índice no agrupado

También hay una miríada de artículos aportados por la comunidad, por ejemplo. Webcast de grabación - Premios Darwin DBA: Índice de edición .

Y para responder a su pregunta específicamente: pueden funcionar índices separados en cada columna , siempre que cada columna tenga una alta selectividad (muchos valores distintos, cada valor aparece solo unas pocas veces en la base de datos). El plan de acceso resultante que usa la combinación hash entre dos escaneos de rango de índice generalmente funciona bastante bien. Las columnas con baja selectividad (pocos valores distintos, cada valor aparece muchas veces en la base de datos) no tienen sentido ser indexadas por sí mismas, el optimizador de consultas simplemente las ignorará. Sin embargo, las columnas de baja selectividad muchas veces son buenas claves compuestas cuando se combinan con una columna de alta selectividad.