Por defecto, el PK está agrupado y, en la mayoría de los casos, está bien. Sin embargo, qué pregunta debe hacerse:
- ¿Debería estar mi PK agrupado?
- ¿Qué columna (s) será la mejor clave para mi índice agrupado?
PK e índice agrupado son dos cosas diferentes:
- PK es una restricción. PK se utiliza para identificar filas de forma exclusiva, pero no existe una noción de almacenamiento. Sin embargo, de manera predeterminada (en SSMS), se aplica mediante un índice agrupado único si aún no existe un índice agrupado.
- Los índices agrupados son un tipo especial de índice que almacena datos de fila a nivel de hoja, lo que significa que siempre está cubriendo. Todas las columnas, ya sean parte de la clave o no, se almacenan a nivel de hoja. No tiene que ser único, en cuyo caso se agrega un uniquifier (4 bytes) a la clave en clúster.
Ahora terminamos con 2 preguntas:
- ¿Cómo quiero identificar de forma exclusiva las filas en mi tabla (PK)
- ¿Cómo quiero almacenarlo en el nivel de hoja de un índice (índice agrupado)
Depende de cómo:
- diseñas tu modelo de datos
- consulta sus datos y escribe sus consultas
- inserta o actualiza sus datos
- ...
Primero, ¿necesita un índice agrupado? Si inserta de forma masiva, es más eficiente almacenar datos desordenados en un HEAP (en comparación con los datos ordenados en un clúster). Utiliza RID (Identificador de fila, 8 bytes) para identificar filas de forma exclusiva y almacenarlo en páginas.
El índice agrupado no debe ser un valor aleatorio. Los datos a nivel de hoja serán almacenados y ordenados por la clave de índice. Por lo tanto, debe crecer continuamente para evitar la fragmentación o la división de la página. Si el PK no puede lograr esto, debe considerar otra clave como candidato agrupado. El índice agrupado en columnas de identificación, GUID secuencial o incluso algo así como la fecha de inserción está bien desde un punto de vista secuencial ya que todas las filas se agregarán a la última página de hoja. Por otro lado, si bien un identificador único puede ser útil para las necesidades de su negocio como PK, no deben agruparse (se ordenan / generan al azar).
Si después de algunos análisis de datos y consultas, descubre que utiliza principalmente el mismo índice para obtener sus datos antes de realizar una búsqueda clave en el PK agrupado, puede considerarlo como un índice agrupado, aunque puede que no identifique sus datos de forma exclusiva.
La clave de índice agrupado se compone de todas las columnas que desea indexar. Se agrega una columna de archivo único (4 bytes) si no tiene una restricción única (valor incremental para duplicados, nulo de lo contrario). Esta clave de índice se almacenará una vez para cada fila en el nivel de hoja de todos sus índices no agrupados. Algunos de ellos también se almacenarán varias veces en niveles intermedios (rama) entre la raíz y el nivel de la hoja del árbol de índice (árbol B). Si la clave es demasiado grande, todo el índice no agrupado se hará más grande, requerirá más almacenamiento y más IO, CPU, memoria, ... Si tiene una PK en nombre + fecha de nacimiento + país, es muy probable que esta clave No es un buen candidato. Es demasiado grande para un índice agrupado. El identificador único que usa NEWSEQUENTIALID () generalmente no se considera una clave estrecha (16 bytes) aunque es secuencial.
Luego, una vez que descubrió cómo identificar filas de forma exclusiva en su tabla, puede agregar un PK. Si cree que no lo usará en su consulta, no lo cree agrupado. Aún puede crear otro índice no agrupado si alguna vez necesita consultarlo. Tenga en cuenta que el PK creará automáticamente un índice único.
Los índices no agrupados siempre contendrán la clave agrupada. Sin embargo, si las columnas indexadas (+ columnas clave) están cubriendo, no habrá ninguna búsqueda clave en el índice agrupado. No olvide que también puede agregar Incluir y Dónde a un índice no agrupado. (úsalo con sabiduría)
El índice agrupado debe ser único y lo más estrecho posible El índice agrupado no debe cambiar con el tiempo y debe insertarse de forma incremental.
Ahora es el momento de escribir algunos SQL que crearán la tabla, los índices y las restricciones agrupados y no agrupados.
Todo esto es teórico porque no conocemos su modelo de datos y los tipos de datos utilizados (A y B).