sql server - tipos - Diferencia entre índice agrupado y no agrupado

nomenclatura indices sql server (6)

Debería usar índices para ayudar al rendimiento del servidor SQL. Por lo general, eso implica que las columnas que se usan para encontrar filas en una tabla están indexadas.

Los índices agrupados hacen que el servidor SQL ordene las filas en el disco según el orden del índice. Esto implica que si accede a los datos en el orden de un índice agrupado, entonces los datos estarán presentes en el disco en el orden correcto. Sin embargo, si la (s) columna (s) que tienen un índice agrupado se cambian con frecuencia, entonces la (s) fila (s) se moverán en el disco, lo que provocará una sobrecarga, lo que generalmente no es una buena idea.

Tener muchos índices tampoco es bueno. Cuestan para mantener. Así que comienza con los más obvios, y luego haz un perfil para ver cuáles extrañas y de qué se beneficiarían. No los necesita desde el inicio, se pueden agregar más adelante.

La mayoría de los tipos de datos de columna se pueden usar al indexar, pero es mejor tener columnas pequeñas indexadas que grandes. También es común crear índices en grupos de columnas (por ejemplo, país + ciudad + calle).

Además, no notará problemas de rendimiento hasta que tenga bastante información en sus tablas. Y otra cosa en que pensar es que SQL Server necesita estadísticas para hacer sus optimizaciones de consultas de la manera correcta, así que asegúrese de generar eso.

Esta pregunta ya tiene una respuesta aquí:

¿Cuáles son las diferencias entre un índice agrupado y un índice no agrupado? 10 respuestas

Necesito agregar el index adecuado a mis tablas y necesito ayuda.

Estoy confundido y necesito aclarar algunos puntos:

¿Debo usar el índice para columnas que non-int ? Por qué por qué no
He leído mucho sobre el índice clustered y non-clustered pero todavía no puedo decidir cuándo usar uno sobre el otro. Un buen ejemplo nos ayudaría a mí y a muchos otros desarrolladores.

Sé que no debería usar índices para columnas o tablas que a menudo se actualizan. ¿De qué más debería tener cuidado y cómo puedo saber que todo está bien antes de ir a la fase de prueba?

En general, use un índice en una columna que se utilizará (mucho) para buscar en la tabla, como una clave principal (que de forma predeterminada tiene un índice agrupado). Por ejemplo, si tiene la consulta (en pseudocódigo)

SELECT * FROM FOO WHERE FOO.BAR = 2

Es posible que desee poner un índice en FOO.BAR. Se debe usar un índice agrupado en una columna que se utilizará para la clasificación. Un índice agrupado se utiliza para ordenar las filas en el disco, por lo que solo puede tener una por tabla. Por ejemplo, si tienes la consulta

SELECT * FROM FOO ORDER BY FOO.BAR ASCENDING

Es posible que desee considerar un índice agrupado en FOO.BAR.

Probablemente la consideración más importante es cuánto tiempo están tomando sus consultas. Si una consulta no toma mucho tiempo o no se usa con mucha frecuencia, puede que no valga la pena agregar índices. Como siempre, primero perfila, luego optimiza. SQL Server Studio puede darle sugerencias sobre dónde optimizar, y MSDN tiene cierta información 1 que podría serle útil

Realmente necesitas separar dos cuestiones:

1) la clave primaria es una construcción lógica: una de las claves candidatas que identifica de forma única y confiable cada fila en su tabla. Esto puede ser cualquier cosa, en realidad, una INT, un GUID, una cadena, elija lo que tenga más sentido para su escenario.

2) la clave del clúster (la columna o columnas que definen el "índice agrupado" en la tabla): esta es una cuestión relacionada con el almacenamiento físico , y aquí, un tipo de datos pequeño, estable y en constante aumento es su mejor opción - INT o BIGINT como su opción predeterminada.

De forma predeterminada, la clave principal en una tabla de SQL Server también se usa como la clave de clúster, ¡pero eso no tiene por qué ser así!

Una regla práctica que aplicaría es la siguiente: cualquier tabla "normal" (una que use para almacenar datos, es decir, una tabla de búsqueda, etc.) debe tener una clave de agrupamiento. Realmente no tiene sentido no tener una clave de agrupamiento. De hecho, contrariamente a lo que se cree, tener una clave de clúster realmente acelera todas las operaciones comunes, incluso inserta y elimina (ya que la organización de la tabla es diferente y generalmente mejor que con un montón ) una tabla sin una clave de agrupamiento.

Kimberly Tripp, la reina de la indexación, tiene muchos excelentes artículos sobre el tema de por qué tener una clave de agrupamiento y qué tipo de columnas usar mejor como clave de agrupamiento. Como solo obtiene uno por mesa, es de suma importancia seleccionar la clave de clúster correcta , y no solo cualquier tecla de agrupamiento.

Bagazo

Un índice agrupado altera la forma en que se almacenan las filas. Cuando crea un índice agrupado en una columna (o un número de columnas), el servidor SQL clasifica las filas de la tabla por esa (s) columna (s). Es como un diccionario, donde todas las palabras están ordenadas en orden alfabético en todo el libro.

Un índice no agrupado, por otro lado, no altera la forma en que se almacenan las filas en la tabla. Crea un objeto completamente diferente dentro de la tabla que contiene la (s) columna (s) seleccionada (s) para la indexación y un puntero a las filas de la tabla que contienen los datos. Es como un índice en las últimas páginas de un libro, donde las palabras clave se ordenan y contienen el número de página del material del libro para una referencia más rápida.

es más rápido de leer que de clúster ya que los datos se almacenan físicamente en orden de índice, solo podemos crear uno por tabla. (índice de clúster)

más rápido para la operación de inserción y actualización que un índice de clúster. podemos crear n número de índice no de clúster.

Una comparación de un índice no agrupado con un índice agrupado con un ejemplo

Como ejemplo de un índice no agrupado, digamos que tenemos un índice no agrupado en la columna EmployeeID. Un índice no agrupado almacenará tanto el valor del

ID de empleado

Y un puntero a la fila en la tabla Empleado donde ese valor se almacena realmente. Pero un índice agrupado, en cambio, almacenará los datos de la fila para un ID de empleado en particular, por lo que si está ejecutando una consulta que busca un ID de empleado de 15, los datos de otras columnas en la tabla

EmployeeName, EmployeeAddress, etc.

. todos se almacenarán realmente en el nodo hoja del índice agrupado.

Esto significa que con un índice no agrupado se requiere trabajo adicional para seguir ese puntero a la fila en la tabla para recuperar cualquier otro valor deseado, en oposición a un índice agrupado que puede acceder a la fila directamente, ya que se almacena en el mismo orden que el índice agrupado en sí. Por lo tanto, leer desde un índice agrupado es generalmente más rápido que leer desde un índice no agrupado.