sintaxis - indices clustered y nonclustered sql server
¿Los índices agrupados deben ser únicos? (3)
¿Los índices agrupados deben ser únicos?
No lo hacen, y hay momentos en que es mejor si no lo son.
Considere una tabla con un Id. De empleado único semialeatorio y un Id. De departamento para cada empleado: si su enunciado seleccionado es
SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%
entonces es mejor para el rendimiento si DepartmentId
es el índice agrupado aunque (o incluso especialmente porque) no es el índice único (mejor para el rendimiento porque garantiza que todos los registros dentro de un DepartmentId determinado estén agrupados).
¿Tienes alguna referencia?
Hay pautas de diseño de índice agrupadas, por ejemplo, que dice:
Con pocas excepciones, cada tabla debe tener un índice agrupado definido en la columna, o columnas, que ofrecen lo siguiente:
- Se puede usar para consultas frecuentes.
- Proporcionar un alto grado de singularidad.
- Puede ser utilizado en consultas de rango.
Mi comprensión del "alto grado de singularidad", por ejemplo, es que no es bueno elegir "País" como el índice encerrado si la mayoría de las consultas desea seleccionar los registros dentro de una ciudad determinada.
¿Qué sucede si un índice agrupado no es único? ¿Puede llevar a un mal rendimiento porque las filas insertadas fluyen a una página de "desbordamiento" de algún tipo?
¿Es "hecho" único y en caso afirmativo cómo? ¿Cuál es la mejor manera de hacerlo único?
Lo estoy preguntando porque actualmente estoy usando un índice agrupado para dividir mi tabla en partes lógicas, pero el rendimiento es regular, y recientemente obtuve el consejo de hacer que mis índices agrupados fueran únicos. Me gustaría una segunda opinión sobre eso.
¡Gracias!
Me gustaría ver lo que la Reina de la Indexación, Kimberly Tripp, tiene que decir sobre el tema:
Comenzaré con mi recomendación para la Clave de Agrupación, por un par de razones. En primer lugar, es una decisión fácil de tomar y, en segundo lugar, tomar esta decisión a tiempo ayuda a prevenir de forma proactiva algunos tipos de fragmentación. Si puede evitar ciertos tipos de fragmentación de la tabla base, entonces puede minimizar algunas actividades de mantenimiento (algunas de las cuales, en SQL Server 2000 Y menos de las cuales, en SQL Server 2005) requieren que su tabla esté fuera de línea. OK, voy a llegar a la reconstrucción de cosas más tarde .....
Comencemos con las cosas clave que busco en una clave de agrupamiento:
* Unique
* Narrow
* Static
¿Por qué único? Una clave de agrupamiento debe ser única porque una clave de agrupamiento (cuando existe) se utiliza como la clave de búsqueda de todos los índices no agrupados. Tomemos, por ejemplo, un índice en la parte posterior de un libro; si necesita encontrar los datos a los que apunta una entrada de índice, esa entrada (la entrada de índice) debe ser única; de lo contrario, qué entrada de índice sería la que está buscando. ? Entonces, cuando crea el índice agrupado, debe ser único. Pero, SQL Server no requiere que su clave de clúster se cree en una columna única. Puede crearlo en cualquier columna que desee. Internamente, si la clave de clúster no es única, SQL Server la "uniquificará" al agregar un entero de 4 bytes a los datos. Entonces, si el índice agrupado se crea en algo que no es único, no solo hay una sobrecarga adicional en la creación del índice, hay espacio en el disco desperdiciado, costos adicionales en INSERTES y ACTUALIZACIONES, y en SQL Server 2000, hay un costo adicional en un índice clustereD reconstruir (lo cual es más probable debido a la mala elección de la clave de agrupamiento).
Fuente: debate clave de agrupación en constante aumento, nuevamente.
No tienen que ser únicos, pero sin duda se fomenta.
Todavía no me he encontrado con un escenario en el que quisiera crear un elemento de configuración en una columna no única.
Qué sucede si crea un CI en una columna no única
Si el índice agrupado no es un índice exclusivo, SQL Server convierte las claves duplicadas en únicas al agregar un valor generado internamente llamado un único elemento
¿Esto lleva a un mal rendimiento?
Agregar un singularizador ciertamente agrega algo de sobrecarga en el cálculo y el almacenamiento.
Si esta sobrecarga será notable depende de varios factores.
- Cuantos datos contiene la tabla
- ¿Cuál es la tasa de insertos?
- ¿Con qué frecuencia se usa el IC en una selección (cuando no existen índices de cobertura, casi siempre).
Editar
como ha señalado Remus en los comentarios, existen casos de uso donde la creación de un IC no exclusivo sería una opción razonable. El hecho de que no haya encontrado uno de esos escenarios simplemente muestra mi propia falta de exposición o competencia (escoja su elección).