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 atravesar páginas requiere un búsqueda en el mapa de asignación de índices .
Sin embargo, una tabla agrupada tiene sus páginas de datos vinculadas en una lista doblemente vinculada - Hacer escaneos secuenciales un poco más rápido. Por supuesto, a cambio, tiene la sobrecarga de mantener las páginas de datos en orden en INSERT , UPDATE y DELETE . Sin embargo, una tabla de almacenamiento dinámico requiere una segunda escritura en el IAM.
Si su consulta tiene un RANGE operador (por ejemplo:SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), entonces una tabla agrupada (estar 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 de la ordenación.
Y, por supuesto, un índice agrupado le permite realizar una BÚSQUEDA DE ÍNDICE CLUSTERADO, que es bastante óptimo para el rendimiento... un montón sin índices siempre daría como resultado un escaneo de tabla.
Entonces:
-
Para su consulta de ejemplo donde 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 poco más rápida que un montón con una gran cantidad de filas.
-
Para una consulta con
WHEREcláusula que puede ser (al menos parcialmente) satisfecha por el índice agrupado, saldrá adelante debido al orden, por lo que no tendrá que escanear toda la tabla. -
Para una consulta que no está satisfecha por el índice agrupado, está bastante igualado... de nuevo, la única diferencia es esa lista doblemente enlazada para el escaneo secuencial. En cualquier caso, estás por debajo del nivel óptimo.
-
Para
INSERT,UPDATEyDELETEun montón puede o no ganar. El montón no tiene que mantener el orden, pero requiere una segunda escritura en el IAM. Creo que la diferencia de rendimiento relativa sería insignificante, pero también dependería bastante de los datos.
Microsoft tiene un documento técnico que compara un índice agrupado con un índice no agrupado equivalente en un montón (no exactamente lo mismo que discutí anteriormente, pero cercano). 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 en realidad están comparando un índice no agrupado con un índice agrupado aquí, pero creo que es relativamente comparable):
INSERTrendimiento:el índice agrupado gana alrededor de un 3 % debido a que se necesita la segunda escritura para un montón.UPDATErendimiento:el índice agrupado gana aproximadamente un 8 % debido a la segunda búsqueda necesaria para un montón.DELETErendimiento:el índice agrupado gana alrededor de un 18 % debido a que se necesita la segunda búsqueda y se necesita la segunda eliminación del IAM para un montón.- solo
SELECTrendimiento:el índice agrupado gana alrededor de un 16 % debido a la segunda búsqueda necesaria para un montón. - rango
SELECTrendimiento:el índice agrupado gana alrededor de un 29 % debido al orden aleatorio de un montón. INSERTsimultáneos :la tabla del montón gana un 30 % bajo carga debido a las divisiones de página para el índice agrupado.
