¿El índice no agrupado de SQL Server 2008 contiene los campos de índice agrupados?

Question

OK, necesito que esto se deletree una vez más. He leído los artículos en línea y aún no he encontrado una respuesta definitiva.

En SQL Server 2008, tengo una tabla "core" con aproximadamente 50k registros y mucha actividad de lectura que se usa de la misma manera en todas las consultas. Esta información se actualiza una vez al mes y se lee cientos de veces por segundo.

Los datos tienen un índice agrupado en los campos, ya que se accede con frecuencia. Digamos que el índice agrupado es:

índice agrupado

Field1 int 
Field2 int 
Field3 int 
Field4 int 
Field5 int 

Ahora, no es mucho más datos que los que, por lo que tendría sentido que sólo hay que poner el extra par de columnas en "Incluido Columnas ", pero SQL Server no permite incluir columnas en el índice agrupado.

Por lo tanto, tenemos un segundo índice con esencialmente los mismos campos que el Índice agrupado, con las otras columnas como "Columnas incluidas". Sin embargo, por lo que he leído, ¿creo que esto puede ser redundante?

CUBIERTA ÍNDICE (no agrupado)

Field1 int 
Field2 int 
Field3 int 
Field4 int 
Field5 int 

columnas incluidas

Field6 varchar(96) 
Field7 varchar(96) 

¿El índice no agrupado ya se disponen de columnas de índice agrupado definido en ella?

En caso afirmativo, ¿cómo podría crearse este segundo índice sin columnas (además de lo que ya figura en el índice agrupado)? En otras palabras, me gustaría decir: "Este índice es exactamente el mismo que el índice agrupado ... con un par de columnas incluidas".

O, ¿sería mejor simplemente poner TODAS las columnas en el índice agrupado (incluidas las dos que no identifican el registro)? Las columnas varchar se actualizan con más frecuencia (algunas veces al día en lugar de una vez al mes), por lo que me hubiera gustado mantenerlas fuera del índice agrupado, pero creo que son lo suficientemente profundas como para que no afecten el árbol de índice lo suficiente como para causar un reequilibrio cuando se produce un cambio.

Entonces, ¿hay una forma eficiente de configurar estos índices para que todas las columnas de esta tabla estén disponibles a través del índice sin volver a la tabla?

Answer 1

Un índice agrupado no necesita incluir. Incluye medios almacenados datos adicionales en el nivel más bajo del árbol de índice. es los datos en un índice agrupado. Por lo tanto, no necesita un índice superpuesto

Sin embargo, si la huella de memoria es su problema, debe reducir la tabla. Con 50k filas, consideraría una pequeña clave sustituta a partir de -32768. Luego, quita la sobrecarga de la tecla C en cada índice NC. Esto significa que puede tener un índice de cobertura como se menciona en su pregunta.

Tenga en cuenta que una vez que sus planes de ejecución se almacenan en caché y los datos están en caché, sus consultas vendrán de la memoria. Su uso significa que permanecerá en la memoria caché por un tiempo. La falta de actualizaciones significa que no obtendrá recompilaciones basadas en estadísticas.

Sin embargo, si sus datos son casi estáticos, ¿por qué llamar a SQL Server si el rendimiento es una preocupación? Caché. Elimine la red de ida y vuelta, que probablemente sea su mayor sobrecarga en función de mis comentarios de almacenamiento en caché. Externalizamos algunas búsquedas y el almacenamiento en caché de nuestros clientes para reducir la carga del servidor (tenemos 50k escribe en alrededor de 20 segundos en la carga máxima)

Answer 2

Sí: un índice sin clúster accede a los datos de la tabla mediante la clave agrupada (cuando la tabla tiene una clave agrupada y la Id. De fila cuando no), por lo que incluirá automáticamente los campos del índice agrupado. Esta es también una razón por la cual un cambio en el índice agrupado obliga a la reconstrucción de todos los índices no agrupados.

El índice NC adicional con los 2 campos incluidos podría ser válido si ese índice satisface una gran cantidad de consultas, pero no estoy seguro de que esté resolviendo el problema correcto.

Incluir 2 campos más dentro de la Clave agrupada no es ideal, ahora se confirma dentro del índice NC, puede ver que todos los índices de esa tabla incluyen la clave agrupada dentro de ella que agrupa cada índice.

Esta es la razón principal por la que desea que su clave en clúster sea lo más estrecha posible; en todo caso, debe examinar su clave agrupada para preguntar por qué elige una clave de 5 campos agrupados y ¿esa elección dará lugar a la fragmentación?

Puede que esté mejor con un valor artificial (Identidad) para la clave agrupada, y use un índice NC exclusivo para aplicar la singularidad que tiene con la clave de 5 campos agrupados.

Answer 3

que tendría sentido que sólo hay que poner la pareja extra de columnas en "Columnas incluidas", pero SQL Server no permite que incluía columnas en las columnas adicionales de índice agrupado

Incluyendo es imposible, porque un índice agrupado ya contiene todas las columnas. Es por eso que el índice se llama agrupado.

Por lo tanto, tenemos un segundo índice con esencialmente los mismos campos que el índice agrupado , con las otras columnas como "Columnas incluidos". Sin embargo, por lo que he leído, I cree que esto puede ser redundante?

Sí, probablemente sea redundante. Existen algunas raras excepciones en las que el índice agrupado no cabe en la memoria.

¿El índice no agrupado YA tienen las columnas de la índice agrupado definido en ella?

Probablemente: un índice no agrupado contiene un puntero al índice agrupado. Si el índice agrupado es único, este puntero consta de todos los campos de índice agrupados. (En la mayoría de las situaciones, estos campos se corresponden con la clave principal.)

Entonces, ¿hay una forma eficiente de establecer estos índices de manera que todos los columnas de esta tabla están disponibles a través del índice sin volviendo a la mesa?

En el ejemplo que publica, parece que el índice agrupado es suficiente y no necesita ningún otro índice para evitar una búsqueda en la tabla. Puede verificar esto ejecutando consultas y buscando operaciones de "búsqueda de clave" o "búsqueda incorrecta".

Answer 4

Creo que necesita una mejor comprensión de los índices CLUSTERED y NCLCLADOS. El índice agrupado es un árbol equilibrado (árbol B) donde cada nodo contiene la columna clave (s) para el índice. Normalmente, y con frecuencia la mejor opción, una columna es la columna clave para el índice. todos los datos para cada fila se almacenan a nivel de hoja (es decir, el nivel inferior) del índice agrupado. Por esta razón, no puede haber incluido columnas en un índice agrupado; todas las columnas están incluidas por definición.

un índice no agrupado también es una estructura B-tree. Cada nodo contiene la (s) columna (s) clave para el índice. El nivel de hoja para índices no agrupados contiene columnas incluidas. Tenga en cuenta que la diferencia entre una columna clave y la columna incluida es que los valores de la columna clave aparecen en cada nivel del índice y las columnas incluidas solo aparecen en el nivel de la hoja.El nivel de la hoja también contiene la (s) columna (s) clave del índice agrupado, que se usan para vincular el índice con los datos de la tabla.

Cuantas más columnas incluya en cualquier índice, mayor será el índice. Y, esto puede degradar el rendimiento.

Por lo tanto, para un índice agrupado, no necesita incluir todas las columnas, o incluso muchas columnas, como claves en el índice. Los datos ya son parte del índice.