sql-server - una - indices sql server

¿Cómo elegir el índice agrupado en SQL Server?

Question

Por lo general, el índice agrupado se crea en SQL Server Management Studio configurando la clave principal; sin embargo, mi pregunta reciente sobre PK <-> índice agrupado ( Significado de la clave principal de Microsoft SQL Server 2008 ) ha demostrado que no es necesario establecer PK y índice agrupado para ser igual.

Entonces, ¿cómo deberíamos elegir índices agrupados? Tengamos el siguiente ejemplo:

create table Customers (ID int, ...) create table Orders (ID int, CustomerID int)

Por lo general, creábamos PK / CI en ambas columnas de ID, pero pensé en crearlo para Pedidos en CustomerID. ¿Es esa la mejor opción?

Answer 1

El mejor candidato para un índice CLUSTERED es la clave que usa para referirse a sus registros con mayor frecuencia.

Por lo general, esta es una PRIMARY KEY , ya que es lo que se usa en las búsquedas y / o en las relaciones FOREIGN KEY .

En su caso, Orders.ID probablemente participará en las búsquedas y referencias, por lo que es el mejor candidato para ser una expresión de agrupamiento.

Si crea el índice CLUSTERED en Orders.CustomerID , Orders.CustomerID las siguientes cosas:

1. CustomerID no es único. Para garantizar la exclusividad, se agregará a cada registro una columna oculta especial de 32-bit conocida como uniquifier .

2. Los registros en la tabla se almacenarán de acuerdo con este par de columnas (CustomerID, uniquifier) .

3. Se Order.ID un índice secundario en Order.ID , con (CustomerID, uniquifier) como punteros de registro.

4. Consultas como esta:

   SELECT *
   FROM Orders
   WHERE ID = 1234567

   tendrá que hacer una operación externa, una Clustered Seek , ya que no todas las columnas se almacenan en el índice de ID . Para recuperar todas las columnas, el registro primero debe ubicarse en la tabla agrupada.

Esta operación adicional requiere IndexDepth tantas lecturas de página como una simple Clustered Seek , IndexDepth beign O(log(n)) del número total de registros en su tabla.

Answer 2

Según The Queen Of Indexing , Kimberly Tripp, lo que ella busca en un índice agrupado es principalmente:

• Único
• Estrecho
• Estático

Y si también puedes garantizar:

• Patrón cada vez mayor

¡entonces estás muy cerca de tener tu llave de agrupamiento ideal!

Eche un vistazo a la publicación completa de su blog aquí , y otra muy interesante sobre el agrupamiento de los principales impactos en las operaciones de la tabla aquí: Continúa el debate sobre el índice agrupado .

Cualquier cosa como una INT (especialmente una IDENTIDAD INT) o posiblemente un INT y un DATETIME son candiates ideales. Por otros motivos, los GUID no son buenos candidatos en absoluto, por lo que puede tener un GUID como su PK, pero no agrupe su tabla en él; estará fragmentado más allá del reconocimiento y el rendimiento se verá afectado.

Answer 3

Si le preocupa la agrupación, generalmente es para ayudar a mejorar la recuperación de datos. En su ejemplo, es probable que desee todos los registros de un cliente determinado a la vez. La agrupación en customerID mantendrá esas filas en la misma página física en lugar de dispersarse en varias páginas de su archivo.

ROT: Agrupa en qué quieres mostrar una colección. Las líneas de pedido en una orden de compra son el ejemplo clásico.