SQL Server Index ¿Qué debería agruparse?

Question

Tengo un número de índices en algunas tablas, todos son similares y quiero saber si el índice agrupado está en la columna correcta. Estas son las estadísticas de los dos índices más activos:

Nonclustered 
I3_Identity (bigint) 
rows: 193,781 
pages: 3821 
MB: 29.85 
user seeks: 463,355 
user_scans: 784 
user_lookups: 0 
updates: 256,516 

Clustered Primary Key 
I3_RowId (varchar(80)) 
rows: 193,781 
pages: 24,289 
MB: 189.76 
user_seeks: 2,473,413 
user_scans: 958 
user_lookups: 463,693 
updates: 2,669,261 

Como se puede ver, el PK está siendo seeked a menudo, pero toda la busca de la columna de la i3_identity están haciendo búsquedas de claves a esta PK, así que estoy Realmente me estoy beneficiando mucho del índice de I3_Identity? ¿Debo cambiar a usar I3_Identity como agrupada? Esto podría tener un gran impacto ya que la estructura de esta tabla se repite alrededor de 10000 veces donde trabajo, por lo que cualquier ayuda sería apreciada.

Answer 1

Frederik lo resume muy bien, y eso es lo que Kimberly Tripp también predica: la clave del clúster debe ser estable (nunca cambia), cada vez mayor (IDENTIDAD INT), pequeña y única.

En su escenario, preferiría poner la clave de agrupamiento en la columna BIGINT en lugar de la columna VARCHAR (80).

En primer lugar, con la columna BIGINT, es razonablemente fácil imponer la exclusividad (si no aplica y garantiza la exclusividad, SQL Server agregará un "únicofier" de 4 bytes a todas y cada una de sus filas) y es MUCHO más pequeño en promedio que un VARCHAR (80).

¿Por qué es tan importante el tamaño? La clave de clúster también se agregará a CADA y a cada uno de sus índices no agrupados, por lo que si tiene muchas filas y muchos índices no agrupados, tener 40-80 bytes contra 8 bytes puede hacer que un ENORME diferencia.

Además, otro consejo de rendimiento: para evitar las llamadas búsquedas de marcadores (desde un valor en su índice no agrupado a través de la clave de agrupación en las páginas de hoja de datos reales), SQL Server 2005 ha introducido la noción de "columnas incluidas" en los índices no agrupados. Esos son extremadamente útiles, y a menudo se pasan por alto. Si sus consultas a menudo requieren los campos de índice más solo uno o dos campos más de la base de datos, considere incluirlos para lograr lo que se denomina "índices de cobertura". De nuevo, ver el excelente artículo de Kimberly Tripp, ¡ella es la diosa de la indexación de SQL Server! :-) y ella puede explicar eso mucho mejor que yo ...

Para resumir: coloque su clave de agrupamiento en una columna pequeña, estable y única, ¡y lo hará bien!

Marc

Answer 2

Según lo que he leído en el pasado, dos de las medidas más importantes con respecto a las tablas de indexación son el número de consultas realizadas contra el índice y la densidad del índice. Al usar DBCC_SHOWSTATISTICS ([tabla], [índice]), puede examinar la densidad del índice. La idea es que desee su índice agrupado en las columnas que proporcionan la mayor distinción por consulta.

En resumen, si nos fijamos en la medida "Todas las densidades" de DBCC SHOW_STATISTICS y observamos que el número es muy bajo, este es un buen índice para agrupar. Tiene sentido lógico agruparse en un índice que proporcione más singularidad, pero solo si se lo consulta activamente. La agrupación en un índice poco utilizado probablemente hará más daño que bien.

Al final es una llamada de juicio. Es posible que desee hablar con su DBA y analizar su código para ver dónde obtendrá el mayor beneficio. En este ejemplo limitado, su indexación parece agruparse en el área correcta si solo considera el uso (e incluso cuando considera toda la densidad, dado el hecho de que una clave principal proporciona la mayor singularidad que puede reunir.)

Editar sección : Hay un artículo bastante bueno en MSDN que explica lo que SHOW_STATISTICS le brinda. Ciertamente no soy un DBA súper, pero la mayoría de la información que he proporcionado aquí vine de la guía que ofrece nuestra DBA :)

Aquí está el artículo: http://msdn.microsoft.com/en-us/library/ms174384.aspx

Answer 3

Here's the best discussion que he encontrado sobre el tema. Kimberly Tripp es una blogger de MS que se mantiene en la cima del debate. Podría interpretarlo por ti, pero obviamente entiendes las palabras y conceptos básicos, y el artículo es muy legible. ¡Así que Disfrutá!

Sugerencia: encontrará que las respuestas cortas son casi siempre demasiado simplistas.

Answer 4

rápida 'n sucia:

Ponga el índice agrupado en:

• una columna que está valores de (casi) nunca cambian

• una columna para que valora el nuevo aumento de los registros/Disminuya secuencialmente

• columna donde realiza el rango - búsquedas

Answer 5

Generalmente, cuando veo búsquedas de claves en la tecla principal/clave en clúster, significa que necesito incluir (usando la instrucción INCLUDE) más columnas en la clave no agrupada. Mire sus consultas y vea qué columnas están siendo seleccionadas/usadas en esas declaraciones. Si incluye esas columnas en la clave no agrupada, ya no será necesario realizar la búsqueda de claves.