SQL Server: ¿cuándo usar el índice agrupado o no agrupado?

Conozco las diferencias principales entre índices agrupados y no agrupados y entiendo cómo funcionan realmente. Entiendo cómo los índices agrupados y no agrupados mejoran el rendimiento de lectura. Pero una cosa de la que no estoy seguro es cuáles serían las razones por las que elegiría una sobre la otra.

Por ejemplo: si una tabla no tiene un índice agrupado, ¿se debe crear un índice no agrupado y cuál es el beneficio de hacer?

— armulator
fuente

Gracias por responder. Ya soy consciente de eso. Mi pregunta es si habría una situación en la que crear un índice no agrupado se beneficiaría más que crear un índice agrupado

— armulator

Sí, debe evitar un índice agrupado cuando; la columna tiene baja cardinalidad, ningún orden en particular, se actualiza con frecuencia, no es secuencial, es un compuesto de muchas columnas ...

— TI

Gracias por tu respuesta. Es útil

— armulator

Quizás esta pregunta te ayude: stackoverflow.com/questions/5070529/…

— David García González

Posible duplicado de ¿En qué columna se debe colocar el índice agrupado?

— Michael Freidgeim

117

Solo quiero hacer una advertencia: ¡ elija con mucho cuidado su índice agrupado! Cada tabla de datos "normal" debe tener un índice agrupado, ya que tener un índice agrupado acelera muchas operaciones; sí, acelera , ¡incluso inserta y elimina! Pero solo si elige un buen índice agrupado.

Es la estructura de datos más replicada en su base de datos de SQL Server. La clave de agrupación también formará parte de todos y cada uno de los índices no agrupados en su tabla.

Debe tener mucho cuidado al elegir una clave de agrupación; debe ser:

estrecho (4 bytes ideal)
único (después de todo, es el "puntero de fila". Si no lo convierte en único, SQL Server lo hará por usted en segundo plano, lo que le costará un par de bytes por cada entrada multiplicada por el número de filas y el número de índices no agrupados tiene - ¡esto puede ser muy costoso!)
estático (nunca cambie, si es posible)
idealmente cada vez mayor para que no termine con una fragmentación de índice horrible (un GUID es todo lo contrario de una buena clave de agrupación, por esa razón en particular)
debe ser no anulable e idealmente también de ancho fijo - a varchar(250)hace una clave de agrupamiento muy pobre

Cualquier otra cosa debería ser un segundo y tercer nivel de importancia detrás de estos puntos ...

Vea algunas de las publicaciones del blog de Kimberly Tripp ( La reina de la indexación ) sobre el tema; todo lo que haya escrito en su blog es absolutamente invaluable; léalo, digígalo, ¡vívelo!

— marc_s
fuente

Gracias marc_s por la clara explicación. Pero técnicamente hablando, ¿qué hace el non clusteredíndice por nosotros? cuales son su importancia ..?

— hud

@nad: un índice no agrupado bien elegido puede acelerar sus búsquedas; en lugar de tener que comparar potencialmente millones de filas de datos con sus criterios de búsqueda, puede encontrar una fila determinada con solo 4, 5 comparaciones. ¡Eso hace una GRAN diferencia!

— marc_s

@MuriloKunze: lea la publicación del blog de Kim Tripp sobre el tema - ella explica con gran detalle por qué este es el caso

— marc_s

Lo siento, pero ¿dónde está la respuesta a la pregunta "SQL Server: cuándo usar el índice agrupado o no agrupado?" ?

— Eduard