nonclustered - Pila de SQL Server vs índice agrupado

primary key clustered sql server

Question

Estoy utilizando SQL Server 2008. Sé que si una tabla no tiene un índice agrupado, entonces se llama montón, o si no, el modelo de almacenamiento se llama índice agrupado (B-Tree).

Quiero aprender más sobre qué significa exactamente almacenamiento en el montón, cómo se ve y si está organizado como una estructura de datos de "montón" (por ejemplo, montón mínimo, montón máximo). ¿Alguna lectura recomendada? Quiero más un poco más internos, pero no demasiado profundos. :-)

gracias de antemano, george

Answer 1

El almacenamiento del montón no tiene nada que ver con estos montones .

Montón simplemente significa que los registros en sí mismos no están ordenados (es decir, no están vinculados entre sí).

Cuando inserta un registro, simplemente se inserta en el espacio libre que encuentra la base de datos.

Actualizar una fila en una tabla basada en montón no afecta a otros registros (aunque afecta a índices secundarios)

Si crea un índice secundario en una tabla HEAP , el RID (un tipo de puntero físico al espacio de almacenamiento) se usa como un puntero de fila.

El índice agrupado significa que los registros son parte de un B-Tree . Cuando inserta un registro, es necesario volver a vincular el B-Tree B.

La actualización de una fila en una tabla agrupada hace que se vuelva a vincular el árbol B, es decir, la actualización de los punteros internos en otros registros.

Si crea un índice secundario en una tabla agrupada, el valor de la clave de índice agrupado se usa como un puntero de fila.

Esto significa que un índice agrupado debe ser único. Si un índice agrupado no es único, se agrega una columna oculta especial llamada uniquifier a la clave de índice que hace que sea único (y de mayor tamaño).

También vale la pena señalar que la creación de un índice secundario en una columna hace que los valores o la clave del índice agrupado formen parte de la clave del índice secundario.

Al crear un índice en una tabla agrupada, de hecho siempre obtiene un índice compuesto

CREATE UNIQUE CLUSTERED INDEX CX_mytable_1234 (col1, col2, col3, col4)

CREATE INDEX IX_mytable_5678 (col5, col6, col7, col8)

El índice IX_mytable_5678 es de hecho un índice en las siguientes columnas:

col5
col6
col7
col8
col1
col2
col3
col4

Esto tiene un efecto secundario más:

Una condición de DESC en un índice de una sola columna en una tabla agrupada tiene sentido en SQL Server

Este índice:

CREATE INDEX IX_mytable ON mytable (col1)

Se puede utilizar en una consulta como esta:

SELECT  TOP 100 *
FROM    mytable
ORDER BY
       col1, id

, mientras este:

CREATE INDEX IX_mytable ON mytable (col1 DESC)

Se puede utilizar en una consulta como esta:

SELECT  TOP 100 *
FROM    mytable
ORDER BY
       col1, id DESC

Answer 2

Los montones son solo tablas sin una clave de agrupación en clúster, sin una clave que impone un cierto orden físico.

Realmente no recomendaría tener montones en ningún momento, excepto si usas una tabla temporalmente para cargar en masa un archivo externo y luego distribuir esas filas a otras tablas.

En cualquier otro caso, recomendaría encarecidamente el uso de una clave de agrupación. SQL Server usará la Clave principal como la clave de agrupamiento por defecto, lo cual es una buena opción, en la mayoría de los casos. A MENOS QUE use un GUID (UNIQUEIDENTIFIER) como su clave principal, en cuyo caso usarlo como su clave de agrupamiento es una idea horrible.

Vea los excelentes GUID de las publicaciones de blog de Kimberly Tripp como principal y / o la clave de agrupación en clúster y el debate de índice agrupado continúa para obtener excelentes explicaciones de por qué siempre debe tener una clave de agrupación en clústeres, y por qué un GUID es una clave de agrupación horrible.

Mi recomendación sería:

• en el 99% de todos los casos, intente usar una INT IDENTITY como su clave principal y deje que SQL Server haga que la clave del clúster también
• excepción # 1: si está cargando grandes cantidades de datos de forma masiva, podría estar bien sin una clave principal / agrupación en clúster para su tabla temporal
• excepción # 2: si debe usar un GUID como su clave principal, entonces configure su clave de agrupamiento en una columna diferente, preferiblemente una INT IDENTITY , e incluso crearía una columna INT separada solo para ese propósito, si ninguna otra columna puede ser usado

Bagazo

Answer 3

Libros en línea es la mejor fuente!

Todo el motor de base de datos - Planificación y arquitectura - Tablas y arquitectura de estructuras de datos de índice es una muy buena introducción interna.

Desde este enlace puede descargar una copia local de Books Online (es gratis). Es la mejor (y oficial) referencia a todas las preguntas de Sql 2008.