¿Por qué la creación de este nuevo índice mejoró tanto el rendimiento cuando el índice existente incluía todas las columnas en el nuevo índice?

Question

Tengo tablas LogItem y Log; Estoy escribiendo una consulta para obtener algunos datos de ambos. Hay miles de Logs y cada Log pueden tener hasta 125 LogItems

La consulta en cuestión se complica así que estoy saltando (si alguien piensa que es importante es probable que pueda publicarlo), pero cuando me encontré con SSMS estimado de consultas plan, me dijo que un nuevo índice no agrupado mejoraría el rendimiento hasta en un 100%.

Existing Index: Non-clustered 
Key Colums (LogItem): ParentLogID, DateModified, Name, DatabaseModified 

Query Plan Recommendation 
CREATE NONCLUSTERED INDEX [LogReportIndex] 
ON [dbo].[LogItem] ([ParentLogID],[DatabaseModified]) 

Sólo por diversión, he creado este nuevo índice y corrieron la consulta y para mi sorpresa, que ahora toma aproximadamente 1 segundo en mi consulta se ejecute, cuando antes era de 10 + segundos.

Supuse que mi índice existente cubriría esta nueva consulta, por lo que mi pregunta es ¿por qué la creación de un nuevo índice en las únicas columnas utilizadas en mi nueva consulta mejora el rendimiento? ¿Debo tener un índice para cada combinación única de columnas utilizadas en mis cláusulas where?

nota: No creo que esto se deba a que el SQL Server está almacenando en caché mis resultados, ejecuté la consulta unas 25-30 veces antes de crear el índice y tardó 10-15 segundos, después del índice ahora es constantemente ~ 1 o menos.

Answer 1

El orden de las columnas en un índice es importante. Si el filtrado requiere la columna 1 y 4 del índice, el índice no ayudará. Solo es útil al filtrar por las primeras N columnas consecutivas.

Esto es porque index es un árbol. No puede seleccionar eficientemente todos los nodos del árbol donde column3 = something, ya que están dispersos por todos los demás, pertenecientes a diferentes valores de column1 y column2. Pero si conoce column1 y column2 también, ubicar la rama derecha en el árbol es pan comido.

Answer 2

El borde de avance de un índice es lo que importa.

Siempre y cuando su consulta esté "cubierta" por una punta de un índice, será eficiente. Los índices de base de datos se implementan típicamente como B-Trees y la estructura del B-Tree dicta que la búsqueda debe realizarse en un orden determinado, por lo que importa el orden de los campos en el índice compuesto.

Si tiene "agujeros", p. si busca en ParentLogID y DatabaseModified, pero solo tiene índice en {ParentLogID, DateModified, Name, DatabaseModified}, entonces solo la porción {ParentLogID} del índice se puede utilizar de manera eficiente.

(NOTA: Algunos DBMSes pueden utilizar la parte {DatabaseModified} través de "exploración con omisión", pero incluso si su DBMS hace que es mucho menos eficiente que el acceso índice normal).