¿Cuál es la diferencia entre un escaneo de tabla y un escaneo de índice agrupado?

Question

Dado que tanto un Table Scan y un Clustered Index Scan Básicamente, escanea todos los registros de la tabla, ¿por qué supuestamente es mejor un escaneo de índice agrupado?

Como ejemplo, ¿cuál es la diferencia de rendimiento entre lo siguiente cuando hay muchos registros?:

declare @temp table(
    SomeColumn varchar(50)
)

insert into @temp
select 'SomeVal'

select * from @temp

-----------------------------

declare @temp table(
    RowID int not null identity(1,1) primary key,
    SomeColumn varchar(50)
)

insert into @temp
select 'SomeVal'

select * from @temp

Answer 1

En una tabla sin un índice agrupado (una tabla de montón), las páginas de datos no están vinculadas entre sí, por lo que recorrer las páginas requiere un busque en el mapa de asignación de índices.

Una tabla agrupada, sin embargo, tiene sus páginas de datos enlazadas en una lista doblemente enlazada - hacer escaneos secuenciales un poco más rápidos.Por supuesto, a cambio, usted tiene los gastos generales de ocuparse de mantener las páginas de datos en orden. INSERT, UPDATE, y DELETE.Sin embargo, una tabla de montón requiere una segunda escritura en el IAM.

Si tu consulta tiene un RANGE operador (por ejemplo: SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100), entonces una tabla agrupada (que esté en un orden garantizado) sería más eficiente, ya que podría usar las páginas de índice para encontrar las páginas de datos relevantes.Un montón tendría que escanear todas las filas, ya que no puede depender del pedido.

Y, por supuesto, un índice agrupado le permite realizar una BÚSQUEDA DE ÍNDICE AGRUPADO, lo cual es bastante óptimo para el rendimiento... un montón sin índices siempre resultaría en una exploración de la tabla.

Entonces:

• Para su consulta de ejemplo en la que selecciona todas las filas, la única diferencia es la lista doblemente vinculada que mantiene un índice agrupado.Esto debería hacer que su tabla agrupada sea un poquito más rápida que un montón con una gran cantidad de filas.

• Para una consulta con un WHERE cláusula que puede ser satisfecha (al menos parcialmente) por el índice agrupado, saldrá adelante debido al orden, por lo que no tendrá que escanear toda la tabla.

• Para una consulta que no se satisface con el índice agrupado, está prácticamente igualado... nuevamente, la única diferencia es esa lista doblemente vinculada para el escaneo secuencial.En cualquier caso, no eres óptimo.

• Para INSERT, UPDATE, y DELETE un montón puede ganar o no.El montón no tiene que mantener el orden, pero requiere una segunda escritura en el IAM.Creo que la diferencia de rendimiento relativo sería insignificante, pero también dependería bastante de los datos.

Microsoft tiene un papel blanco que compara un índice agrupado con un índice no agrupado equivalente en un montón (no es exactamente lo mismo que mencioné anteriormente, pero se acerca).Su conclusión es básicamente poner un índice agrupado en todas las tablas.Haré todo lo posible para resumir sus resultados (nuevamente, tenga en cuenta que aquí realmente están comparando un índice no agrupado con un índice agrupado, pero creo que es relativamente comparable):

• INSERT actuación:El índice agrupado gana aproximadamente un 3% debido a la segunda escritura necesaria para un montón.
• UPDATE actuación:El índice agrupado gana aproximadamente un 8% debido a la segunda búsqueda necesaria para un montón.
• DELETE actuación:El índice agrupado gana aproximadamente un 18 % debido a la segunda búsqueda necesaria y la segunda eliminación necesaria del IAM para un montón.
• soltero SELECT actuación:El índice agrupado gana aproximadamente un 16% debido a la segunda búsqueda necesaria para un montón.
• rango SELECT actuación:El índice agrupado gana aproximadamente un 29% debido al orden aleatorio de un montón.
• concurrente INSERT:La tabla de montón gana un 30% bajo carga debido a las divisiones de páginas para el índice agrupado.

Answer 2

http://msdn.microsoft.com/en-us/library/aa216840(SQL.80).aspx

El operador físico y lógico de escaneo de índice agrupado escanea el índice agrupado especificado en la columna Argumento.Cuando está presente un predicado WHERE:() opcional, solo se devuelven aquellas filas que satisfacen el predicado.Si la columna Argumento contiene la cláusula ORDERED, el procesador de consultas ha solicitado que la salida de las filas se devuelva en el orden en que las clasificó el índice agrupado.Si la cláusula ORDERED no está presente, el motor de almacenamiento escaneará el índice de la manera óptima (sin garantizar que la salida se ordene).

http://msdn.microsoft.com/en-us/library/aa178416(SQL.80).aspx

El operador lógico y físico de Table Scan recupera todas las filas de la tabla especificada en la columna Argumento.Si aparece un predicado WHERE:() en la columna Argumento, solo se devuelven aquellas filas que satisfacen el predicado.

Answer 3

Un escaneo de tabla debe examinar cada fila de la tabla.El escaneo de índice agrupado solo necesita escanear el índice.No escanea todos los registros de la tabla.En realidad, ese es el objetivo de los índices.