Razones para no tener un índice agrupado en SQL Server 2005

Question

He heredado algunos scripts de creación de bases de datos para una base de datos SQL SERVER 2005.

Una cosa que he notado es que todas las claves principales se crean como índices NON CLUSTERED en lugar de agrupados.

Sé que solo puede tener un índice agrupado por tabla y que puede querer tenerlo en una columna de clave no primaria para el rendimiento de búsqueda de búsquedas, etc. Sin embargo, no hay otros índices CLUSTERED en las tablas en cuestión.

Así que mi pregunta es ¿existen razones técnicas para no tener índices agrupados en una columna de clave principal aparte de los anteriores.

Answer 1

En cualquier tabla de datos o búsqueda "normal": no, no veo ningún motivo en absoluto.

En cosas como las tablas de importación masiva, o tablas temporales, depende.

Sorprendentemente, parece que tener un buen índice agrupado puede acelerar operaciones como INSERT o UPDATE. Vea la excelente publicación de blog de Kimberly Tripps The Clustered Index Debate continues.... en la que explica con gran detalle por qué este es el caso.

En esta luz: No veo ninguna razón válida no tener un buen índice agrupado (estrecha, estable, único, cada vez mayor = INT IDENTITY como la elección más obvia) en cualquier tabla de SQL Server .

Para obtener algunas ideas profundamente en cómo y por qué elegir teclas de agrupamiento, lea todas las excelentes publicaciones en el blog de Kimberly Tripp sobre el tema:

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx

Excelente cosas de la "Reina de indexación "!:-)

Answer 2

Clustered Tables vs Heap Tables

(Buen artículo sobre tema en www.mssqltips.com)

PAFH Tabla (Sin índice agrupado)

• datos no se almacenan en ninguna en particular fin

• Datos específicos c una no se va a recuperar rápidamente, a menos que también hay índices no agrupados

• páginas de datos no están vinculados, por lo de acceso secuencial necesita referirse de nuevo al mapa de asignación de índices (IAM) páginas

• Dado que no existe un índice agrupado, tiempo adicional no es necesaria para mantener el índice

• Dado que no existe un índice agrupado, no hay TH e la necesidad de espacio adicional para almacenar el índice agrupado árbol

• Estas tablas tienen un valor de index_id 0 en la vista de catálogo sys.indexes

Tabla clúster

• Los datos se almacenan en orden según la clave de índice agrupado

• datos pueden ser recuperados rápidamente basan en la clave del índice agrupado, si la consulta utiliza las columnas indexadas

• páginas de datos están vinculados a de acceso secuencial rápido se necesita tiempo adicional para mantener el índice agrupado basa en inserciones, actualizaciones y eliminaciones

• se necesita espacio adicional para almacenar agrupados árbol del índice Estas tablas tienen un valor de 1 index_id en el catálogo sys.indexes view

Answer 3

Aquí hay otro (¿ya se ha proporcionado en otras respuestas?) Razón posible (aún no se ha entendido):

• SQL Server - Poor performance of PK delete

espero, deberá actualizar más adelante, pero por ahora es más bien el deseo de vincular estos temas

Actualización:
What do I miss in understanding the clustered index?

Answer 4

Lea mi respuesta en "No hay acceso directo a la fila de datos en la tabla agrupada - ¿por qué?", primero. Específicamente ítem [2] Advertencia.

Las personas que crearon la "base de datos" son cretinos. Tenían:

• un montón de spreadhseets desnormalizados, no normalizados tablas relacionales
• las PK se todas las columnas de identidad (las hojas de cálculo están vinculados entre sí, tienen que ser navegado uno por uno por uno); no hay acceso relacional o poder relacional a través de la base de datos de
• tenían PRIMARY KEY, que producen ÚNICA CLUSTERED
• encontraron que que impedía la concurrencia
• le quitaron la IC y ellos hicieron todo NCIS
• que eran demasiado perezoso para terminar la inversión; a designar un suplente (corriente NCI) para convertirse en el nuevo CI, para cada tabla
• la columna IDENTITY sigue siendo la clave principal (que no es realmente, pero es en esta implementación hamfisted)

Para tales colecciones de hojas de cálculo enmascaradas como bases de datos, cada vez es más común evitar las EC por completo, y solo tienen NCI más el Heap. Obviamente no obtienen el poder o los beneficios de la IC, pero diablos, no obtienen el poder o beneficio de las bases de datos relacionales, entonces ¿a quién le importa que no obtengan el poder de los CI (que fueron diseñados para bases de datos relacionales, que son suyas? no es). Por la forma en que lo ven, tienen que "refactorizar" la maldita cosa de vez en cuando de todos modos, entonces, ¿para qué molestarse? Las bases de datos relacionales no necesitan "refactorización".

Si necesita analizar más esta respuesta, publique CREATE TABLE/INDEX DDL; de lo contrario, es un argumento académico que pierde el tiempo.

Answer 5

Con algunos servidores/lenguajes de programación b-tree que aún se usan en la actualidad, los archivos ascii planos de longitud fija o variable se utilizan para almacenar datos. Cuando se agrega un nuevo registro/fila de datos a un archivo (tabla), el registro se (1) se agrega al final del archivo (o reemplaza un registro eliminado) y (2) los índices se equilibran. Cuando los datos se almacenan de esta manera, no tiene que preocuparse por el rendimiento del sistema (en lo que respecta al funcionamiento del servidor b-tree para devolver un puntero al primer registro de datos). El tiempo de respuesta solo se ve afectado por el número de nodos en sus archivos de índice.

Cuando empiece a usar SQL, con suerte se dará cuenta de que se debe tener en cuenta el rendimiento del sistema cada vez que se escribe una instrucción SQL. Usar una instrucción "ORDER BY" en una columna no indexada puede poner a un sistema de rodillas. Usar un índice agrupado podría poner una carga innecesaria en la CPU. Es el siglo 21 y me gustaría no tener que pensar en el rendimiento del sistema cuando se programa en SQL, pero aún lo hacemos.

Con algunos lenguajes de programación anteriores, era obligatorio utilizar un índice cada vez que se recuperan datos ordenados. Solo desearía que este requisito todavía estuviera vigente hoy. Solo me puedo preguntar cuántas empresas han actualizado sus sistemas informáticos lentos debido a una declaración SQL mal escrita sobre datos no indexados.

En mis 25 años de programación, nunca he necesitado mis datos físicos almacenados en un orden particular, así que tal vez es por eso que algunos programadores evitan usar índices agrupados. Es difícil saber cuál es la compensación (tiempo de almacenamiento, tiempo de recuperación de versículos), especialmente si el sistema que está diseñando puede almacenar millones de registros algún día.