2012-03-07 15 views
5

Por lo que yo entiendo, cada transacción ve su propia versión de la base de datos, por lo que el sistema no puede obtener el número total de filas de algún contador y, por lo tanto, necesita escanear un índice. Pero pensé que sería el índice agrupado en la clave principal, no los índices adicionales. Si tuviera más de un índice adicional, ¿cuál será elegido?¿Por qué hay un análisis de índice no agrupado cuando se cuentan todas las filas en una tabla?

Al profundizar en el asunto, me he dado cuenta de otra cosa extraña. Supongamos que hay dos tablas idénticas, artículos y artículos2, cada uno con tres columnas: Id, View_Count y Title. El primero tiene solo un índice agrupado basado en PK, mientras que el segundo tiene un índice adicional no agrupado y no único en view_count. La consulta SELECT COUNT(1) FROM Articles se ejecuta 2 veces más rápido para la tabla con el índice adicional.

Respuesta

8

SQL Server optimizará su consulta: si necesita contar las filas en una tabla, elegirá el conjunto de datos más pequeño posible para hacerlo.

Por lo tanto, si considera su índice agrupado, contiene las páginas de datos reales, posiblemente varios miles de bytes por fila. Cargar todos esos bytes solo para contar las filas sería un desperdicio, incluso solo en términos de E/S de disco.

Por lo tanto, si hay un índice no agrupado que no está filtrado o restringido de ninguna manera, SQL Server seleccionará esa estructura de datos para contar, ya que el índice no agrupado contiene básicamente las columnas que ha colocado en el NC índice (más la clave del índice agrupado): mucha menos información para cargar solo para contar el número de filas.

+0

Sí, me di cuenta cuando publiqué la segunda parte y miré el plan con más cuidado. La exploración de índice agrupado tiene el mismo costo de CPU pero un costo de E/S más alto. – synapse

Cuestiones relacionadas